System for maintaining presentation instrument data

ABSTRACT

According to one embodiment of the invention, an architecture is provided for a data processing system that processes data for a service provider itself or a client of a service provider as in the case of a third party processor. The elements of the architecture can be managed separately. For example, the architecture can be organized around eight subject areas, such as account, party, communication point, presentation instrument, rules, balances, transactions, and product. Relationships between each of the subject areas as well as between sub-types of each subject area can be established to provide flexibility in the management of the data.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit under 35 USC §119(e) of U.S. PatentApplication No. 60/547,651, filed on Feb. 24, 2004 entitled “System andMethod for Transaction Processing” as well as the benefit under 35 USC §19(e) of U.S. Patent Application No. 60/567,891, filed May 3, 2004,entitled “System and Method for Transaction Processing” and herebyincorporates by reference the content of both applications in theirentirety and for all purposes.

STATEMENT AS TO RIGHTS TO INVENTIONS MADE UNDER FEDERALLY SPONSOREDRESEARCH OR DEVELOPMENT

NOT APPLICABLE

REFERENCE TO A “SEQUENCE LISTING,” A TABLE, OR A COMPUTER PROGRAMLISTING APPENDIX SUBMITTED ON A COMPACT DISK

NOT APPLICABLE

Embodiments of the invention relate generally to systems for processingdata for service industries. For example, one embodiment of theinvention relates to a system for processing utility usage transactionsand generating bills. Yet another embodiment relates to processingcredit card transactions for the credit card (retail, debit, consumer)industry. Still other embodiments of the invention relate to processingtransactions generated on accounts for healthcare payments, homemortgage, consumer loans, telephone usage, for example.

BACKGROUND

Credit card transaction management and administration is an example of aprocessing system that has traditionally relied on storing a great dealof information with a single identifier used as a reference. Forexample, a credit card account typically includes information about thecustomer, the account, the billing address, the formal transactioninformation, and the credit card and physical credit cardcharacteristics. All of this is handled from the perspective of a singleaccount, so that the credit card company can track transactions for aparticular customer. Thus, this results in a very static data processingsystem that is inflexible which makes it difficult to effect changes asthe business it services evolves. Furthermore, the handling of thisinformation is typically specific to a particular line of businesswithin an industry such as a revolving credit product for the financialservices industry. It is not readily aligned with a totally differentservice model, such as one's utility billing system, insurance claimpayment processing system, phone billing system, or cable billingsystem.

Thus, a third party which handles the processing of transactions for avariety of different industries or services must create independentsystems for handling each service's transactions. There currentlyappears to be no unique system which is capable of flexibly handlingdifferent types of services, such as credit card processing, healthcareclaim payment, and utility bill processing, in the same processingsystem. Again, the static and inflexible nature of the currentprocessing systems prevent this.

In addition, because the account information, party information, andpresentation instrument information for a credit card system, forexample, is referenced by a single identifier, it is quite difficult, ifnot impossible, under present systems, to manage the individual areas ofaccount information, party information, or presentation instrument asindependent data. Once again, the inflexible nature of a singlereference to the data prevents this from happening.

As another example of the inflexibility of current systems, it is noteasy to modify existing systems to add multiple parties and therequisite roles they play to an account and utilize multiple cards forthat account. Again, this is difficult due to the fact that once anaccount is created under the static formatting of a particularaccount—such as the formatting of a Mastercard Gold Card with a singlecustomer—it is extremely difficult to modify that record to reflectchange—such as a second party, playing a previously unsupported role, onthe account—without restructuring the processing system (underlying datastructures and program code).

Another example of the inflexibility of credit card systems is thatcustomers are typically prevented from playing dual roles in an account,such as the role of guarantor and authorized user. Instead, the creditcard account is typically configured to identify one party as theauthorized user and a different party as the guarantor. Once again, thisprevents the flexibility that might be desired in certain circumstances.

Yet another example of the rigidity of current systems is that, forproducts offered by a bank, for example, which offers different creditcard lines as well as brokerage accounts and mortgages, each of thoseindividual accounts is typically processed separately, under separatesystems. It is not possible to easily combine those systems at a laterpoint in time under a master account which could be tailored to theservices desired by a particular customer.

As yet another example, the static nature of current systems makes itdifficult, if not impossible, to modify the mailing contact points foran individual during different times of the year. For example, a creditcard statement is typically mailed to a home residence of the customerwho is financially responsible for the account. Current systems do notprovide the flexibility to allow a customer to designate varyinglocations during the year to which statements should be sent. This isdue to the fact that only a single address is currently associated witha credit card account, for example, without the flexibility to designatedifferent contact points throughout the year. To include suchinformation would require a complete reworking of the credit cardprocessing system because the credit card processing system operates byreferring to all account information using a single referenceidentifier.

Thus, as can be seen from the above examples, current processing systemsfor service industries are typically configured in a static andinflexible way so as to effectively prevent the efficient management ofinformation for an account. Other examples addressed by presentembodiments of the invention will be apparent from the followingspecification.

Thus, there is a need for a data processing system which can handle theprocessing of data for service industries in a more flexible manner. Forexample, there is a need for a data processing system and requisite dataarchitecture that can easily adapt to changing business requirements andis not tightly coupled with a specific aspect of any one service or anyone industry.

SUMMARY

According to one embodiment of the invention, a method of storing datafor use in implementing a transaction for an account is provided whereinthe method comprises storing data for identifying a presentationinstrument for an account as an entry in a presentation instrumentdatabase; generating an internal identifier for use with the entry; andassigning the internal identifier with the record so as to be able toretrieve the data for identifying the presentation instrument byreferencing the internal identifier.

According to another embodiment of the invention, a method of storingdata for use in implementing a transaction for a party is providedwherein the method comprises storing data for identifying a presentationinstrument for a party as an entry in a presentation instrumentdatabase; generating an internal identifier for use with the record;assigning the internal identifier with the record so as to be able toretrieve the data for identifying the presentation instrument byreferencing the internal identifier.

According to yet another embodiment of the invention, a method ofstoring data for defining the characteristics of a presentationinstrument device is provided comprising storing data as an entry foridentifying a presentation instrument device for use as a presentationinstrument in a presentation instrument device database; generating aninternal identifier for use with the entry; and assigning the internalidentifier with the entry so as to be able to retrieve the data foridentifying the presentation instrument device by referencing theinternal identifier.

According to yet another embodiment of the invention, a method ofstoring presentation instrument data is provided comprising providing afirst database for storing a first record for a presentation instrument;providing a second database for storing a second entry for apresentation instrument device, wherein the presentation instrumentdevice is associated with the presentation instrument; assigning a firstinternal identifier with the presentation instrument; storing the firstinternal identifier assigned to the presentation instrument as part ofthe first entry; assigning a second internal identifier with thepresentation instrument device; and storing the second internalidentifier assigned to the presentation instrument device as part of thesecond entry.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating the architecture of a dataprocessing system for managing service industry data according to oneembodiment of the invention.

FIG. 1B illustrates a data processing system for implementing thearchitecture shown in FIG. 1A.

FIGS. 2A and 2B illustrate a flowchart for implementing a method ofprocessing data for a service business according to one embodiment ofthe invention.

FIGS. 3A and 3B illustrate a flowchart for implementing a method ofprocessing data according to one embodiment of the invention.

FIG. 4 illustrates a flowchart for processing data in a party-accountrelationship, according to one embodiment of the invention.

FIGS. 5A and 5B illustrate a flowchart demonstrating a method ofprocessing data in a party-account relationship, according to oneembodiment of the invention.

FIG. 6 illustrates a flowchart demonstrating a method of processing datafor a party-account-presentation instrument relationship, according toone embodiment of the invention.

FIGS. 7A and 7B illustrate a flowchart for implementing a method ofprocessing data for a party-account-presentation instrument relationshipaccording to one embodiment of the invention.

FIG. 8 illustrates a flowchart for implementing a method of processingdata for a party-communication point relationship according to oneembodiment of the invention.

FIG. 9 illustrates a flowchart for implementing a method of processingdata for a party-communication point relationship according to oneembodiment of the invention.

FIG. 10 illustrates a flowchart for implementing a method of processingdata for a product-account relationship, according to one embodiment ofthe invention.

FIG. 11 illustrates a flowchart for implementing a method of processingdata for a product-account relationship, according to one embodiment ofthe invention.

FIG. 12 illustrates a flowchart for implementing a method of processingdata for a product-account relationship, according to one embodiment ofthe invention.

FIG. 13 illustrates a block diagram of a computing system forimplementing any of the computer processing systems in the embodimentsof the invention described herein.

FIG. 14 illustrates a flowchart for implementing a method of processingdata for an account-balance relationship, according to one embodiment ofthe invention.

FIG. 15 illustrates a flowchart for implementing a method of processingdata for a product-balance relationship, according to one embodiment ofthe invention.

FIGS. 16A and 16B illustrates a block diagram of an exemplaryconfiguration for the Communication Point subject area, according to oneembodiment of the invention.

FIGS. 17A and 17B illustrate a block diagram of an exemplaryconfiguration for the presentation instrument subject area, according toone embodiment of the invention.

FIG. 18 illustrates a block diagram of an exemplary configuration forthe party subject area, according to one embodiment of the invention.

FIGS. 19A, 19B, 19C, 19C1, 19D, 19D1, and 19D2 illustrate a blockdiagram of another exemplary configuration for the party subject area,according to one embodiment of the invention.

FIGS. 20A, 20B, and 20C illustrate a block diagram of an exemplaryconfiguration for the account subject area, according to one embodimentof the invention.

FIGS. 21A, 21B, and 21C illustrate a block diagram of an exemplaryconfiguration for the transaction subject area, according to oneembodiment of the invention.

FIG. 22 illustrates a block diagram of an exemplary configuration forthe product subject area, according to one embodiment of the invention.

FIG. 23 illustrates a block diagram of an exemplary way of relatingentries in different databases for facilitating one embodiment of theinvention.

DETAILED DESCRIPTION

Referring now to FIG. 1A, a data architecture for implementing anembodiment of the invention is shown. Namely, in FIG. 1A, a dataarchitecture is shown that is divided into eight different subjectareas, relationships between the subject areas, and the resultingassociations between them. For example, FIG. 1A illustrates in system100 the following subject areas: party 101, account 102, presentationinstrument 103, communication point 104, transaction 105, balance 106,product 107 and rules 108. Furthermore, between subject areas, differentassociations are shown. For example, between party 101 and communicationpoint 104, party-communication point associations 130 is shown.Similarly, between party 101 and account 102, an account-party roleassociation is shown. Furthermore, between presentation instrument 103and account-party role associations 120, a presentationinstrument-account-party role 122 relationship is shown. Similarly,communication point usage 132 is shown positioned between theparty-communication point associations 130 and the account-party-roleassociations 120. FIG. 1A also shows between product 107 and balance106, the product-balance associations 150. Furthermore, it shows betweenaccount 102 and product 107, an account-product associations 160.Finally, between account 102 and balance 106, FIG. 1A shows anaccount-balance associations 140.

FIG. 1B illustrates a processing system for implementing the dataarchitecture shown in FIG. 1A. Furthermore, each of the subject areas,relationships, and associations shown in FIG. 1A are illustrated by acomputer and database in FIG. 1B. A computer and database can be used tostore independently the information for each subject area: party 101′,account 102′, presentation instrument 103′, communication point 104′,transaction 105′, balance 106′, product 107′, and rules 108′. Inaddition, a database and computer can be utilized to store theinformation for each relationship established between the differentsubject areas. For example, the database can be used to store internalidentifiers from the party database and account database in database120′ for storing information in regard to an account-party role.Similarly, a database can be utilized to store information for theparty-communication point relationship as database 130′. Other databasesare shown in FIG. 1B in conformance with FIG. 1A, such as communicationpoint usage database 132′, PI-account-party-role database 122′,account-balance database 140′, account-product database 160′, andproduct-balance database 150′. Each database is designated inconformance with the architecture shown in FIG. 1A.

Each of the computers and databases shown in FIG. 1B can be implementedby the exemplary computer system illustrated in FIG. 13. FIG. 13 broadlyillustrates how individual system elements can be implemented. System1300 is shown comprised of hardware elements that are electricallycoupled via bus 1308, including a processor 1301, input device 1302,output device 1303, storage device 1304, computer-readable storage mediareader 1305 a, communications system 1306 processing acceleration (e.g.,DSP or special-purpose processors) 1307 and memory 1309.Computer-readable storage media reader 1305 a is further coupled tocomputer-readable storage media 1305 b, the combination comprehensivelyrepresenting remote, local, fixed and/or removable storage devices plusstorage media, memory, etc. for temporarily and/or more permanentlycontaining computer-readable information, which can include storagedevice 1304, memory 1309 and/or any other such accessible system 1300resource. System 1300 also comprises software elements (shown as beingcurrently located within working memory 1391) including an operatingsystem 1392 and other code 1393, such as programs, applets, data and thelike.

System 1300 has extensive flexibility and configurability. Thus, forexample, a single architecture might be utilized to implement one ormore servers that can be further configured in accordance with currentlydesirable protocols, protocol variations, extensions, etc. However, itwill be apparent to those skilled in the art that embodiments may wellbe utilized in accordance with more specific application requirements.For example, one or more system elements might be implemented assub-elements within a system 1300 component (e.g. within communicationssystem 1306). Customized hardware might also be utilized and/orparticular elements might be implemented in hardware, software(including so-called “portable software,” such as applets) or both.Further, while connection to other computing devices such as networkinput/output devices (not shown) may be employed, it is to be understoodthat wired, wireless, modem and/or other connection or connections toother computing devices might also be utilized. Distributed processing,multiple site viewing, information forwarding, collaboration, remoteinformation retrieval and merging, and related capabilities are eachcontemplated. Operating system utilization will also vary depending onthe particular host devices and/or process types (e.g. computer,appliance, portable device, etc.) Not all system 1300 components willnecessarily be required in all cases.

The data architecture shown in FIG. 1A provides a great deal offlexibility for managing data or providing data processing for a serviceindustry. Prior data architectures in the credit card industry, forexample, relied upon the referencing of all the information for acustomer's account through the use of a single identifier. Similarly, inthe utility billing system, all the information for a particular user isreferenced as a single set of combined data. The architectureillustrated in FIG. 1A does not reference all of the information for aservice by a single identifier for a static record. Rather, it separatesinformation into distinct subject areas. Thus, one is capable ofproviding a great deal of flexibility to data processing. For example,one can modify the data for a particular party without disruptingprocessing of that party's account. Essentially, no restructuring ofother subject areas is required because an individual subject area canbe modified without impacting the other subject areas. Therefore, thistype of system provides a great deal of flexibility and functionalitythat existing systems cannot accomplish.

Referring to FIG. 1A, the various subject areas can be seen.Furthermore, the relationships and resulting associations establishedbetween many of the different subject areas can be seen as well. Theserelationships and associations permit the processing of stored data fordesired functionality.

Account

Referring to block 102 of FIG. 1A, the account subject area can be seen.The account subject area is a collection of data about the mechanismused to record, measure, and track financial and non-financialinformation related to a contractual agreement. Accounts can becharacterized by specific components, terms or conditions of data of theservice or product that prompted the account's creation. An account canfurther be characterized by financial and demographic data. Thus,according to one embodiment of the invention, the account facilitatesthe management, tracking, and reporting of transaction activities. Thespecific characteristics of an account may vary based on the type ofproduct, product components, party, or terms and conditions establishedin the contractual agreement.

An account is associated to one or more parties who can use one or morepresentation instruments to generate transactions. Furthermore,according to one embodiment of the invention, an account, a party, and apresentation instrument can operate as independent subject areas and canbe related in an association to form a unique occurrence of therelationship.

The account subject area provides for the separation of account datafrom party data and presentation instrument data. Thus, the identity ofa party who fulfills a specific business role for a particular accountis not stored as part of the account database. Rather, it is kept in theparty database and related to the account database where the assignedbusiness role is maintained. Similarly, the data describing thepresentation instrument, such as a credit card or smart card, is notstored as part of the account's data. Rather, this information can berelated with the account's data by an association database.

An account can participate in one or more relationships with otheraccounts, for example, as a member of a business group or family groupof accounts. Furthermore, multiple presentation instruments can generatetransactions for a single account, a group of accounts, or a singlemember of a group. Thus, a single account could be related with a smartcard, a magnetic stripe card, a biometric identifier, etc., each ofwhich could be utilized to initiate a transaction associated with theaccount.

For example, an individual account associated with several parties canbe related with one presentation instrument to generate transactions.Alternatively, a family account with each family member havingindividual or subordinate accounts can be implemented with the accountsubject area. Furthermore, a corporate account with one or moredependent accounts could be implemented through the account database.Thus, it is clear that by segregating data for an account, flexibilityis provided under the data architecture shown in FIG. 1A.

Party

Referring to FIG. 1A, the party 101 subject area can be seen. The partysubject area is a collection of data about individuals, organizations,or organization units that the service provider needs to haveinformation about in order to carry out business operations eitherdirectly or indirectly. Parties can be related to other parties as wellas to accounts, presentation instruments, balances, products,communication points, and transactions. They can participate inagreements, groups, and organizations. They can act as owners, stewards,contact points, and catalysts of business functions and rules.

For example, customer John Joseph Doe may be known to one client of thedata processor as J. Doe, and to another client of the data processor asJ. Joseph Doe, Sr. Each client (e.g., Bank One and XCEL Energy) may adda different address for John Doe even though both have the same socialsecurity number for him and both know that his birth date was Jun. 10,1942. The names used by one client of the data processor are notcombined with those used by the other clients of the data processorbecause each is relevant only within the context of the business thatprovided the information. The party subject area however can storeidentifying information for the party, such as name and social securitynumber that can be related to many different accounts.

The account to which a party is associated is not stored as part of theparty's database. Similarly, the communication point at which a partycan be contacted is also not stored as part of the party's database.Rather, the account and/or communication point are related to the partyby associative databases.

The party database can provide flexibility to maintain multiple names,statuses, and alternative identifiers for an individual, organization,or organizational unit. It also allows a service organization to managemultiple roles in relationships for an individual, organization, ororganizational unit. It further allows one to build and maintainstructural relationships between individuals, organizations, and/ororganizational units such as peer-to-peer relationships or hierarchicalrelationships.

Examples of the relationships between parties are customers of a serviceprovider (credit card companies, utility companies, healthcareproviders), clients of a data processing system such as receiving banks,vendors, merchants, contacts, business partners, and employees.

Presentation Instrument

Referring again to FIG. 1A, a block 102 entitled “presentationinstrument” is shown. The presentation instrument subject area is acollection of data about physical or virtual devices used as atransaction catalyst to generate transactions, either monetary ornon-monetary. The presentation instrument data is stored independentlyfrom party and account data in order to facilitate its management.Characteristics of presentation instrument data can be modified withoutaffecting the account or the account status. Presentation instrumentsare not restricted to being physical devices, such as paper invoices,plastic credit cards, plastic magnetic stripe cards, or smart cards.Rather, they can also be virtual devices, such as a stated accountnumber or an electronic identifier. Any catalyst for initiating atransaction against an account is considered a presentation instrument.

The presentation instrument data can be independently managed. Thus, thepresentation instrument data may be related to one or moreparty/product/account relationships. For example, a party could requirereissuance of a “presentation instrument”, such as a credit card,without affecting other credit cards on the same account. Similarly, avirtual presentation instrument could be created for an account to allowthe party to enable e-commerce activity without affecting any associatedphysical presentation instruments.

Communication Point

Another subject area shown in FIG. 1A is communication point 104. Thecommunication point subject area identifies the destination points usedfor the delivery of communications, e.g., the virtual or physical pointswhere communication(s) can be received. A communication point can be ageographic address; an electronic address, such as an email address; atelecommunication number, such as a telephone or fax number; or anyother type of destination point to which a communication can beaddressed. Typically, an association will be established between a partyand a communication point to describe the relationship of the party to aparticular communication point; e.g., one geographic address might berelated to a party as the party's home address, another to a party asthe party's work address, etc. These associations can be stored in adifferent database and/or can be used to specify what types ofcommunications can be delivered to them. However, the communicationpoint database stores information about the communication point itselfto which relationships are established and various types ofcommunications are sent.

One of the benefits of storing information in a communication pointdatabase is that the information can readily be changed when the issuingbody changes the content for the communication point. Furthermore, manydifferent communication points can be utilized for a single party byrelating the party to those communication points and/or a singlecommunication point can be related to many parties. This provides greatflexibility for sending communications to a party depending upon thetype of relationship that party has with a communication point and thetime at which that relationship is used. Another example of the inherentflexibility is that as business requirements change and new types ofcommunication points are discovered they can be added to the processingsystem with very little effort.

For example, a communication point could be used to send a specificparty the annual statement for a credit card company. The party may onlylive at its home address for part of the year and live at a differentaddress for another part of the year, as is often the case for retirees.Thus, multiple communication points could be included in a communicationpoint database and an association could be established with the partydatabase to specify the relationship, timing, and usage of thecommunication point data. These associations can be stored in differentdatabases such as party-communication point database 130 andcommunication point usage database 132. Thus, the annual statement couldbe directed to one or more geographic or e-mail addresses during a firstpart of the year and yet a single geographic address during another partof the year.

One of the benefits of storing information in a communication pointdatabase is that the communication point information can change withoutthe relationship to a party changing. Thus, for example, if a districtrevises the zip code configuration for a city, the zip code for alocation can change but the relationship as the primary mailing addresswill not change. Thus, only the communication point database needs to beupdated with the revised zip code information. This can be important insome industries such as the credit card rating industry in which one'scredit rating is determined in part by how many times one has moved. Thearbitrary redistricting of zip codes, for example, would cause one'saddress to change, by definition, under the old data processing methodseven though the geographic location did not change. Thus, the creditrating rules used to evaluate applicants would consider the change inzip code to be a change in address, causing the credit rating for anindividual to worsen—even though the person never moved. However, thesystem shown in FIG. 1A allows the characterization of the geographicaddress, i.e., the revised zip code information, to be entered withoutindicating that the relationship to that geographic location haschanged. Thus, under the system shown in FIG. 1A, a post office thatrevises the zip codes for an individual would not affect the creditrating for that individual. This is yet another example of theflexibility and efficiency of the separation of data brought about bythe data processing architecture shown in FIG. 1A.

As another example of the functionality that can be achieved withseparated communication point data and unique party-communication pointassociations, one can envision all the different types of communicationsthat can be sent for a credit card account. Thus, a monthly statementcould be directed to a home address for six months of the year and avacation address for the remaining six months of the year. Furthermore,an overcredit warning could be sent to an email address if oneapproaches the limit on a credit card. Furthermore, a late paymentnotice could be faxed to one's home address or a second late noticecould be implemented by a telephone call to the individual's home phone.Each of the above communication destinations (i.e. home address, e-mailaddress, fax, telephone) could easily be altered and stored in thecommunication point database. However, associations between the partyand any “address” in the communication point database can be maintainedseparately in a database. Thus, in comparison with traditional creditcard systems in which a statement, for example, is always sent to thesame address, this embodiment of the invention provides greaterflexibility for communicating with a party.

Transaction

Referring again to FIG. 1A, the transaction subject area 105 is shown.The transaction subject area stores data relating to transactionsconducted for a service. The transaction subject area stores acollection of data about business actions or events that impact impliedfinancial worth or cause movement of funds from one account to anotherand/or impact non-financial properties (e.g., names, addresses, requestsfor new plastics). Thus, the transaction database can store informationrelating to previous purchases for a credit card account, for example.Similarly, it can store utility bill payments or billing statements fora utility service. Essentially, it stores all the data that memorializestransactions that occur for an account. In the case of the credit cardindustry, many of the service groups such as Mastercard and Visa have apredefined format for storing transaction information. The transactionsubject area can understand these external formats, can document them asthey are presented, and can broker them into internal format that can beposted to the appropriate balances on an associated account.

Balance

The balance subject area 106 in FIG. 1A is utilized to store balanceinformation for products and accounts. Essentially, a balance is a totalmaintained by balance type and period for an account or account partyrole that serves as a mechanism for accumulating financial(debit/credit) activity. Examples of an account balance are the balancedue on a utility bill or a credit card bill. This balance informationcan include the date of the balance, the amount of the balance, etc. Thebalance database keeps a balance history for each account as desired.

The balance database provides a great deal of flexibility in the typesof balances that can be kept for an account. For example, a promotionalbalance can be used for a new product, such as a new credit card line. Alate fee balance can be kept separate for a credit card as well.Similarly, an overlimit balance can be kept for an account. In addition,a big ticket promotional balance can be utilized for an account. Suchpromotional balances might include how much one pays toward a specificproduct such as a refrigerator. Thus, if a special promotional programis in existence for refrigerators, for example, the balance database canstore how much money has been applied towards purchases which triggerthe grant of the reward towards the refrigerator.

Thus, the balance database provides for all different kinds of balanceinformation to be kept that can be utilized for an account or specifiedfor a particular product line. It provides great flexibility in that thebalance information can be varied and different balances can be selectedfor a product line.

Product

The product subject area 107 is a collection of data about a named itemor service intended for sale by one party to another party for thepurpose of generating revenue. Thus, parties who participate in productcampaigns typically take on different roles such as those who offerproducts to market, those who service a product, and those who use theservices provided by the product. As an example of those who offer aproduct to market, an issuing bank which issues credit cards tocustomers is one example. Similarly, a money transfer agent such asWestern Union, which offers money transfer services to parties, isanother example. Similarly, companies that operate as third parties forissuing and acquiring banks, such as First Data Resources and First DataMerchant Services, fall into this category as well. As an example ofthose who service a product, First Data Resources or any other thirdparty processor is an example of one who performs this service. Finally,as an example of those who use the services provided by the product, aconsumer using a credit card is an example of that category.

Products can be defined by party-selected component data. This replacesprogram-implemented features and functionality. Thus, an issuing bankparty can select the components that it wishes to include as part of anew product to be offered to the purchasing public, each of which wouldbe a separate party. This allows the issuing bank, for example, toselect the interest rate, credit line, payment options, etc.

Another example of a product is a utility service. Thus, the rate forgas and electricity can be defined separately. In addition, the latefees can also be defined as separate components. The party offering sucha product in this example would be the utility company while thehomeowners would be the consumers.

Typically, a product will define the hierarchical nature of components,such as rollup balance, and summary statements. It can also defineaccount balances, such as promotional balances and fees. Furthermore, itcan define the treatment of those balances. In addition, it can definehow the balances are affected by transactions, such as sales, payments,reversals, etc.

Products can vary by different lines of business, such as credit,retail, e-commerce, cellular, etc. A product will typically organizecomponent data in such a way that a business person can use them, aclient can understand them, and an application can process them. Thisallows an unlimited number of components to define a party's product.Furthermore, it allows a faster time to market for new products or tomake changes to existing products. Furthermore, it provides acentralized and easily accessible database for product definitions.

Examples of products are a merchant service; a funds transfer service; aVisa™ Platinum with reward feature; a Mastercard™ Gold Card account; aretail card; an investment cash management service; a cellulartransaction/billing account; and an electric utility billing service.

Rules

The final subject area illustrated in the architecture shown in FIG. 1Ais the rules 108 subject area. The rules subject area is a set of dataused to provide a decision and action infrastructure. A client of theservice provider or the service provider itself can give a rule adefinition of an action enabler within which it manages its business.Detection of business events can trigger party-defined business logicmanaged within the rules subject area. The rules subject area managesprocessing controls comprised of business logic and parameters that aretranslated into executable code.

Thus, the rules database 108 can be utilized throughout the processingsystem depicted in FIG. 1B and FIG. 13 and to support the associationsbetween other subject areas. For example, in the communication pointusage database 132, rules can be invoked to determine when a particularparty should be contacted at a communication point triggered by abusiness event. The rules database can be invoked to trigger a decisionand resulting action depending on the formatting of the rule.

One example of use of the rules database would be as follows:

-   -   If customer's state is “CA” and the transaction is an ATM cash        advance, perform CASH FEE 1    -   Action Set: calculate 4% of the transaction amount    -   Add $1.00 to the previous result    -   Assess the amounts    -   Otherwise, if the transaction is an ATM cash advance, perform        CASH FEE 2    -   Action Set: calculate 4% of the transaction amount    -   Assess the amount.

Subject Area Associations

The various subject areas have been described above as independentdatabases for storing information related to a service business.Relationships exist between the different subject areas and differentcomponents within the subject areas. These relationships result inassociations that can be configured as databases for storing relationalinformation between the subject area databases. While independentdatabases are typically used to describe the sets of data for differentsubject areas, it is also envisioned that separate databases could beused to store information for more than one subject area and theassociations between them.

Block 130 in FIG. 1A shows a party communication point associativedatabase. The party communication point associative database includes agrouping of data related to the party 101 database and communicationpoint 104 database so that entries from each of those databases can belinked or coupled with one another. This allows information from theparty and communication point databases to be associated so that thedata stored separately can be put to use. One way to accomplish this isby associating an internal identifier for an entry from the partydatabase 101 with an internal identifier for an entry from thecommunication point database 104 as an entry in the party-communicationpoint database. Yet another internal identifier can be coupled withthese two ID's, used to indicate the type of association that has beencreated, to form a unique entry. However, this is not necessarilyrequired as the grouped internal identifiers can be identified and thentheir associated information can be obtained from the appropriatesubject area database. In other words the association between the twoidentifiers is that the first internal identifier represents the subjectand the second internal identifier represents the object of therelationship. Thus, the internal identifier for the communication pointcould be the subject and the identifier for the party could be theobject so as to indicate that: “This specific communication is the homeaddress for this specific party.”

Thus, the architecture shown in FIG. 1A illustrates that a servicebusiness can be broken into different individualized subject areas.These subject areas can be kept separate from the other subject areas toallow the management of the information stored for each subject areaseparate and distinct from the management of the other storage areadata. This permits a great deal of flexibility in the manipulation ofdata for a particular subject area.

FIG. 2A illustrates the principle of dividing the architecture intoseparate subject areas. Namely, in flowchart 200 of FIGS. 2A and 2B,party data can be stored for a business as an independent set of data inblock 204. Furthermore, in block 208, account data can be stored for thebusiness as an independent set of data. Similarly, presentationinstrument data for the business can be stored as an independent set ofdata in block 212 and one can store product data for the business as anindependent set of data in block 216. Communication point data can bestored as an independent set of data in block 220, while balance datafor the business can be stored as an independent set of data in block224. Furthermore, rules data for the business can be stored as anindependent set of data in block 228.

FIGS. 3A and 3B further illustrate another example of this principle. Inblock 304 of flowchart 300, one stores party data for a business as anindependent set of data. In block 308, account data for the business isstored as an independent set of data. In block 312, presentationinstrument data is stored for the business as an independent set ofdata. As illustrated by block 316, each of the sets of data is stored ona separate database. Storing the data on separate databases is acharacteristic of this particular example and is not necessarilyrequired if each of the sets of data can be maintained separately. Inblock 320, each of the independent sets of data is stored withoutreference to any of the other sets of data.

While party, account, and presentation instrument data sets can bestored independently, relationships between them can be established bymanaging associations defined by a specific service business. In block324, a set of data to establish the relationship between party data,account data, and presentation instrument data is stored. To accomplishthis, a first internal identifier is assigned to a set of data in theparty database. Furthermore, a second internal identifier is assigned toa set of data in the account database, and a third internal identifieris assigned to a set of data in the presentation instrument database, asshown by block 328. These internal identifiers are grouped together,within a service business context, to form a set of internal identifierswhich can be used to obtain data from each of the party, account, andpresentation instrument databases for creating a specific instance ofrelated information or set of data. A fourth internal identifier, whichhas been assigned to a party, can be utilized to associate a secondparty with the account as shown in block 332. Furthermore, a fifthinternal identifier, which has been assigned to a specific presentationinstrument, can be used to associate a second presentation instrumentwith the account as shown by block 336. Furthermore, each of theparties, i.e., the first and second parties, can be assigned a role asdefined by a service provider for an account, as shown by block 340. Itshould be understood that a service provider can be a data processor ora client of a data processor. For example, First Data Resources ofOmaha, Nebr. can act as a service provider or provide processingservices for banks.

Account-Party Role

Referring to FIG. 1A, an example of a relationship between two subjectareas can be seen. Namely, an association between the party subject area101 and the account subject area 102 can be established to define therole that a party plays on an account in an account/party role database120. This can be accomplished by associating party data with accountdata in the account party role database. An internal identifiergenerator can be utilized to generate internal IDs for each entry ineach database. Thus, internal IDs can be generated for each instance ofdata stored in the party database as can internal IDs be generated foreach set of data in the account database. The selected data elementsfrom each database can be associated together by storing the internalIDs for each as a set of data in the account party role database alongwith the role which indicates the business reason for the association.

FIG. 23 illustrates an example of how data from two databases can beassociated with one another. For example, a specific account in theaccount database 102 can be related to a specific party in the partydatabase 101. This can be accomplished by obtaining the internalidentifiers that have been assigned to the party of interest and theaccount of interest and storing them together as a new instance ofrelated information in the account party role database 120. In additionto storing the internal identifiers of the party and the account, anattribute of role is added that completes the association. Thus, forexample, the first entry shown in block 120 of FIG. 23 illustrates thatthe internal identifier 000A from the account database 102 has beenassociated with the internal identifier 0001 from the party database101. Furthermore, the role information of “guarantor” has been added toindicate that the party identified as 0001 in the party database playsthe role of guarantor on the account identified by the 000A entry in theaccount database. This is but one example of how data can be associatedtogether to specify more detailed entries. TABLE A INTERNAL INTERNALACCOUNT ACCOUNT ACCOUNT PARTY PARTY ID ROLE TYPE ID ID Joe Smith 0001Guarantor Revolving RC123456789 000A Credit Mary Smith 0002 AuthorizedRevolving RC123456789 000A User Credit Mary Smith 0002 FinanciallyElectric U987654 000B Responsible Utility Acme 0003 Accountant RevolvingRC123456789 000A Accounting Credit Officer 0004 Fraud RevolvingRC567891234 000C Grear Investigator Credit

Table A shows a grouping of information to define the role played by aparty on a specific account. Thus, in the example of a revolving creditaccount, different parties can be assigned different roles for a singleaccount. For example, Table A shows that Joe Smith has been establishedas the guarantor on a revolving credit account with the account ID ofRC123456789. Similarly, Mary Smith has been established as theauthorized user role on the same account. Finally, Acme Accounting hastaken on the role of being the accountant for that revolving creditaccount. Thus, this example shows that party data can be coupled withaccount data and roles can be assigned to specific parties for a singleaccount.

Table A also shows that the association can be accomplished by obtainingthe internal party ID “0001” and the internal account ID “000A” and thedata entry of “guarantor” as the role and storing that set of data inthe account party role database. Thus, when that instance or set ofinformation is retrieved from the account party role database, the datathat has been assigned internal party ID 0001 can be retrieved from theparty database to gain identifying information for Joe Smith while thedata that has been assigned internal account ID 000A can be retrievedfrom the account database to show that account ID RC123456789, arevolving credit account, is the account referred to for that entry.Similarly, the account party role database will store the role to beplayed on that account as guarantor. Thus, this is an example of how theparty information and account information can be stored as separate setsof data or information, yet be utilized by another database to establishan association between two sets of information.

Table A demonstrates that, within the account party role database,multiple roles can be established for multiple parties on a singleaccount. Furthermore, the example of Table A illustrates thatrelationships can be stored on the same database for different products,e.g., a revolving credit account, an electric utility account, and adifferent revolving credit account.

The account party role associative database is further illustrated inFIG. 4. In flowchart 400 of FIG. 4, block 404 shows that party data fora party is stored as an independent set of data. Furthermore, block 408shows that account data for an account is stored as an independent setof data. Finally, block 412 shows that an entry in the party data isassociated with an entry in the account data and assigned a role thatthe party plays on an account.

Table A further demonstrates the architecture shown in FIG. 1A.Essentially, a party, which is either an individual (Joe Smith, MarySmith, Mike Grear) or an organization (Acme Accounting, Cross DepartmentStore, Public Power District, Mega Telephone, First Data Corporation)contracts with another party for a service and an account is created.The terms and conditions of the products contained within that servicedepend on the line of business the service provider is in. For eachindustry-defined type of account, there are specific roles to which aparty can be assigned. The business model of the service providerdefines the roles and rules around which those roles are assigned.Managing the roles on the account party role database allows arelationship between the party and account to change without affectingthe party or account data and creates business value. For example, as aparty's role to an account is removed or changed, business value can becreated by retaining the history of the relationship role the party hadwith the account. The history of the role is kept by changing the statusand date on the account party role instance that is no longer valid andby adding a new account party instance for the new role instead ofupdating the existing account party role instance with the new role.

FIGS. 5A and 5B illustrate in more detail the method shown in FIG. 4. Inblock 504 of flowchart 500, party data identifying a party is stored asan independent set of data. In block 508, account data which identifiesan account is stored as an independent set of data. In block 505, afirst identifier is assigned to the party data, while in block 509, asecond identifier is assigned to the account data. In block 512, theparty data is associated with the account data and assigned a role so asto identify the party as playing a role on the account. This can beaccomplished by entering in the account-party role database a particularrole that is assigned to a party identifier and an account identifier.For example, in block 524, the first identifier can be associated withthe second identifier so as to link or relate the party with theaccount, wherein the party data comprises a name of the party, andwherein the account data comprises an account type and an accountidentifier for identifying a specific account of the account type. Inblock 528, a specific role is assigned to the party and accountassociation so as to establish the role played by the party on theaccount. This can be accomplished by storing the first identifier,second identifier, and role as a set of data stored on the account partyrole database. Thus, this allows the party information to be stored andmanaged independently from the account data while still establishing arelationship between the two.

PI-Account-Party Role

After a party has been assigned a role on an account, a presentationinstrument may be assigned that will be used to generate transactions.This ternary association among the party, the account, and thepresentation instrument is useful under the architecture shown in FIG.1A. TABLE B INTERNAL INTERNAL ACCOUNT ACCOUNT ACCOUNT INTERNAL PARTYPARTY ID ROLE TYPE ID ID PI TYPE PI ID PI ID Joe Smith 0001 GuarantorRevolving RC123456789 000A Transponder PI987654321 Z001 Credit Mary 0002Authorized Revolving RC123456789 000A Plastic PI123456788 Z002 SmithUser Credit Mary 0002 Financially Electric U987654 000B Meter M78542573Z003 Smith Responsible Utility

Table B illustrates an example of data relationships identified by thePI/account/party/role database 122 of FIG. 1A. Namely, Table B showsparty information, role information, account information, andpresentation instrument information. Also shown are internalidentifiers. The internal identifiers correspond with entries in each ofthe three databases. By associating the internal identifiers in thePI/account/party/role databases, the entries of information listed inTable B could be obtained. Alternatively, the party role and accountinformation could be obtained from the internal identifiers associatedin an entry in the account party role database.

The management of access to an account is established or eliminated forindividuals or organizations by applying the proper status or addingother presentation instrument types and identifiers for a specificparty. The business model of the particular service provider canindicate which role on the account may receive a presentationinstrument. The service provider can also decide which combination ofPI/account/party/role makes sense for its business. For example, asingle presentation instrument shared by multiple individuals for oneaccount can be utilized or a single presentation instrument shared bymultiple individuals for several accounts can be utilized. Similarly,multiple presentation instruments for a single individual can beutilized for a single account or multiple presentation instrumentsshared by multiple individuals can be utilized for one account. Thus,many associations between PI/account/party/role that make business sensefor a service provider are allowed by the architecture shown in FIG. 1A.

Table B illustrates an example of how two parties can play differentroles on different accounts with different presentation instruments. Forexample, for revolving credit account RC123456789, Joe Smith can playthe role of guarantor while Mary Smith plays the role of authorizeduser. Joe Smith is entitled to use a presentation instrument of atransponder type with the presentation instrument identifier ofP1987654321 while Mary Smith is entitled to use the presentationinstrument of a plastic type having presentation instrument ID numberP1123456788. In this same database, an electric utility service can besupported by indicating that Mary Smith plays the role of a responsibleparty on an electric utility account having ID number U987654 whereinthe presentation instrument is the meter located at Mary Smith'sresidence having ID number M78542573.

FIG. 6 illustrates an example of implementing Table B, for example. Inflowchart 600, block 604 shows that one can store party data identifyinga party as an independent set of data. In block 608, one can storeaccount data identifying an account as an independent set of data. Inblock 612, one can store presentation instrument data identifying apresentation instrument as an independent set of data. In block 616, onecan utilize the party/account/role data, and the presentation instrumentdata to identify a party on an account accessible via a givenpresentation instrument.

FIGS. 7A and 7B illustrate a more detailed example of the combination ofpresentation instrument, account, and party role data. In flowchart 700,party data is stored for identifying a party as an independent set ofdata in block 704. In block 707, a first identifier is associated withthe party data. In block 709, account data for identifying an account isstored as an independent set of data, such as in database 102. In block711, a second internal identifier is associated with the account data.In block 713, the party data is associated with the account data andassigned a role so as to identify the party as playing a role on theaccount. In Block 715, presentation instrument data for identifying apresentation instrument is stored as an independent set of data in block715. In block 717, a third internal identifier is associated with thepresentation instrument data. Each of these identifiers can be internalidentifiers generated by the system architecture for management of thedatabases. Block 719 reflects that the party data, the account data, andthe presentation instrument data can be stored on separate databasessuch as party database 101, account database 102, and PI database 103.In block 721, the first identifier, the second identifier, and the thirdidentifier are associated as a set of data so as to relate the party,the account, and the presentation instrument with one another. In block723, one can utilize the party data, the account data, and thepresentation instrument data to identify a party on an accountaccessible via the presentation instrument. Thus, as shown in Table B,internal identifiers are associated with the party data, the accountdata, and the presentation instrument data.

Party-Communication Point

FIG. 1A illustrates another relationship between two subject areas,namely the relationship between the party subject area and thecommunication point subject area. A party-communication point databasecan be established to define the relationship that an individual,organization, or organization unit has with a type of communicationpoint. Thus, this allows one to establish whether the type ofassociation is a home, employer, temporary, return address, etcregardless of the communication point type (geographic, electronic,telephonic, etc.).

This database of the party-communication point information is useful inthat it allows a service provider to understand how many of theirservice users have a relationship with the same communication point formarketing and cost-reduction purposes. For example, a credit cardcompany can determine how many letters it is sending to the samecommunication point with advertisements. If a family of card holdersresides at the same address, multiple mailings may be sent thereinadvertently when one would suffice. Similarly, billing statementscould be combined for the same party who has multiple accounts but islocated at one communication point. TABLE C INTERNAL INTERNAL PARTYRELATIONSHIP COMM COMM COMM PARTY ID TYPE POINT ID TYPE PT. ID Joe Smith0001 Home CP123456789 Geographic H0001 Mary Smith 0002 EmployerCP787663524 Geographic H0002 Mary Smith 0002 Home CP123456789 GeographicH0001 Acme 0003 Return Address CP918273764 Geographic H0003 AccountingOfficer Grear 0004 Employer CP567891234 Geographic H0004

Table C illustrates an example of a relationship of information that canbe identified by a party communication point database. An entry is shownfor the party Joe Smith and communication point ID CP123456789. Thisentry further indicates the association between the communication pointand Joe Smith as home and that it is a geographic communication point.Table C further illustrates the fact that the communication point withidentifier CP123456789 is used by both Joe and Mary Smith as their homeaddress.

Referring now to FIG. 8, flowchart 800 illustrates a method ofimplementing a party communication point database. In block 804, partydata identifying a party is stored as an independent set of data, suchas in party database 101. In block 808, communication point dataidentifying a communication point is stored as an independent set ofdata, such as in communication point database 104. In block 812, theparty data is associated with the communication point data and theassociation is assigned a type.

A further example is shown in FIG. 9. In block 904 of flowchart 900,party data identifying a party is stored as an independent set of data.In block 908, a first identifier is associated with data for a specificparty. In block 912, communication point data identifying acommunication point is stored as an independent set of data. In block916, a second identifier is associated with the data for thecommunication point. In block 918, a communication point classificationtype is assigned to the communication point data entry. In block 920,the first identifier is associated with the second identifier as asingle data entry so as to relate the specific set of party data withthe specific set of communication point data and so as to identify thecommunication point as being assigned to the party. In block 936, acommunication point relationship type is assigned to the association forthe specific set of party data and the specific set of communicationpoint data. This can be accomplished by storing the first identifier,second identifier, and communication point relationship type as a set ofdata stored on the party communication point type database. Thus thisallows the party information to be stored and managed independently fromthe communication point data while still establishing a relationshipbetween the two data entries.

Communication Point Usage

Referring now to Table D, the relationship of communication point usagecan be better understood. TABLE D ACCOUNT PARTY ROLE TYPE ACCOUNT ID JoeSmith Guarantor Revolving Credit RC123456789 Joe Smith GuarantorRevolving Credit RC123456789 Mary Smith Authorized User Revolving CreditRC123456789 Mary Smith Payor Electric Utility U987654 Acme AccountingAccountant Revolving Credit RC123456789 Officer Grear Fraud InvestigatorRevolving Credit RC567891234 USES RELATIONSHIP COMM PARTY TYPE POINT IDCOMM TYPE Joe Smith Home CP123456789 Geographic Joe Smith HomeCP123456789 Geographic Joe Smith Home CP123456789 Geographic Mary SmithEmployer CP787663524 Geographic Acme Bank Return Address CP918273764Geographic Officer Grear Employer CP567891234 Geographic Usage TypePlastics Statements Letters All Communications Statement Fraud Contact

The communication point usage relationship allows a party communicationpoint to be associated with an account party role. The account partyrole entries indicate the role that a specific party will play on anaccount. The party communication point indicates a communication pointfor a particular party. By linking entries for the party communicationpoint and the account party role, a specific usage can be added as well.Thus, a type of communication can be indicated. Table D illustratesthree sets of data, the party/communication point data, and theparty/account role set of data, and usage types for thesecross-referenced entries. For example, the first entry in theparty/account role database is for Joe Smith as guarantor on an account.Furthermore, the first entry in the party/communication database is forJoe Smith's geographic home location. The first entry for the usage typeis plastics. Thus, Table D illustrates that any communications relatingto plastics, such as new credit cards, are sent to Joe Smith at hisgeographic home address. Similarly, the second entry in each of thethree sets of data indicates that statements are sent to Joe Smith asguarantor to his home geographic address. The third entry indicates thatany letters for Mary Smith in her role as authorized user on therevolving credit account RC123456789 are to be sent to Joe Smith's homegeographic address. However, the fourth entry indicates that anycommunications to Mary Smith in her role as the payor for electricutility account U987654 are to be sent to Mary Smith's employer'sgeographic address. The fifth entry indicates that any statementcommunication for Acme Accounting as accountant on revolving creditaccount RC123456789 are to be sent to the geographic return addressentry for Acme Accounting identified by communication point IDCP918273764. The sixth entry indicates that any fraud contacts forrevolving credit account RC567891234 should be sent to Officer Grear inhis role as fraud investigator at his employer's geographic addressindicated by communication point ID CP567891234.

The example of Table D indicates that, once entries are established indifferent relationship databases, they may be combined for furtherrelationships. Thus, an entry in the account party role database 120 canbe associated to an entry in the party communication point database 130to establish a communication point usage entry in communication pointusage database 132. Again, internal identifiers can be associated witheach entry in the account party role database and the partycommunication point database to associate instances (i.e., data) fromeach of those databases. Furthermore, each of those associations caninclude additional information such as the usage type (plastics,statements, letters, all communications, return address, fraud contacts,etc.) for that particular entry.

Account Product

Referring now to Table E, yet another relationship shown in FIG. 1A canbe understood. The product database 107 and the account database 102 canestablish an account product relationship database 160. The accountproduct association allows several products to be attached to a singleaccount. This allows, for example, a transaction to use the mostadvantageous set of product terms for which the party has contracted.Table E illustrates different product types such as revolving credit,loyalty program, checking, brokerage, electric utility, and levelpayment. Table E also illustrates that the same account's ID is includedfor the revolving credit, loyalty program, checking, and brokerageaccounts, and that another ID is associated with the electric utilityand level payment product types. TABLE E INTERNAL INTERNAL PRODUCT TYPEPRODUCT ID ACCOUNT ID ACCOUNT ID Revolving Credit P001 RC123456789 000ALoyalty Program P002 RC123456789 000A Checking P003 RC123456789 000ABrokerage P004 RC123456789 000A Electric Utlity P005 U987654 000B LevelPayment P006 U987654 000B

Thus, for example, when a customer wants to receive a billing statement,the common account ID number can be used to include all of the differentproduct types in the same mailing. Thus, distinct products such aschecking and revolving credit can be included in the same statementmailing since the same account ID applies to both of them.

FIG. 10 illustrates a flowchart 1000 for implementing the accountproduct relationship database. In block 1004, data for multiple producttypes is stored wherein each of the plurality of the product typesdesignates a product having defined parameters. In block 1008, data foran account is stored as an independent set of data wherein the accountis identified by an account identifier. In block 1012, the data for theplurality of product types is associated with the data for the accountso as to associate the plurality of product types with the accountidentifier so that each of the plurality of product types is related tothe account by the account identifier.

FIG. 11 illustrates another example of the account product relationship.In flowchart 1100, block 1104 indicates that the data is stored for aproduct type wherein the product type designates a product havingdefined parameters. In block 1108, data is stored for an account as anindependent set of data, wherein the account is identified by an accountidentifier. In block 1112, the data for the product type is associatedwith the data for the account so as to relate the account with theproduct type.

Referring to FIG. 12, a flowchart 1200 further illustrates the accountproduct relationship. In block 1204, data is stored for a product type,wherein the product type designates a product having defined parameters.In block 1212, a first identifier is associated with the data for theproduct type. This can be seen in Table E by the internal product IDP0001 being associated with product type “revolving credit.” In block1214, data is stored for an account as a separate set of data, whereinthe account is identified by an account identifier. In block 1216, asecond identifier is associated with the data for the accountinformation. Thus, internal account ID 000A is associated with accountID RC123456789. In block 1220, the first identifier is associated withthe second identifier so as to associate the data for the product typewith the data for the account. Furthermore, in block 1224, a second setof data for a second product type is associated with the accountidentifier so as to identify a plurality of product types with theaccount identifier. This is illustrated by Table E, in which therevolving credit, loyalty program, checking, and brokerage accounts areall associated with account ID RC123456789.

Account Balance

Once the account product database information is established, accountbalance relationships can be established as well. The account balancerelationship associates the balances defined in the terms and conditionsof a product to a specific account. TABLE F INTERNAL PRODUCT/ INTERNALPRODUCT ACCOUNT BALANCE BALANCE TYPE ACCOUNT ID ID TYPE ID RevolvingRC123456789 PA0001 Open To B0001 Credit Buy Revolving RC123456789 PA0001Cash B0002 Credit Revolving RC123456789 PA0001 Credit B0003 CreditRevolving RC123456789 PA0001 Interest B0004 Credit Loyalty RC123456789PA0002 Points B0005 Program Checking RC123456789 PA0003 Balance B0006Brokerage RC123456789 PA0004 Stock B0007 Electric U987654 PA0005 MegaWatts B0008 Utility Used Level U987654 PA0006 Payment B0009 PaymentBalance to Date

Table F illustrates the account product information of Table Eassociated with specific balance types. For example, revolving creditaccounts associated with account ID RC123456789 can be linked to fourdifferent balances. Namely, Table F shows that balance types of “open tobuy”, “cash”, “credit”, and “interest” can be established as individualbalance types for account RC123456789. Similarly, the loyalty programproduct associated with account ID RC123456789 can be established with apoints balance. The checking product associated with account IDRC123456789 can be associated with a checking balance and the brokerageproduct associated with account ID RC123456789 can be associated with abalance type of “stock”. The electric utility product associated withaccount U987654 can be associated with a balance type of “megawattsused” while the level payment product associated with the account IDU987654 can be associated with the balance type of “payment balance todate”.

To establish the relationship between the product and accounts andbalance type, internal identifiers can once again be generated for eachentry in the account database and each entry in the balance database.Then, the internal identifiers can be associated and stored in theaccount balance database. The association of the internal identifiersassociates the information shown as entries in Table F.

Referring now to FIG. 14, a method of implementing the account balancerelationship can be seen. FIG. 14 illustrates a flowchart 1400 for amethod of relating an account with a balance. As can be seen in FIG. 14in block 1404, account data for identifying a particular account isstored as an independent set of data. Similarly, in block 1412, balancedata identifying a balance is stored as an independent set of data. Inblock 1421, the account data and balance data are stored on separatedatabases. Thus, the account data can be stored on the account databaseand the balance data can be stored on the balance database.

In block 1407, a first identifier is assigned to the account data.Similarly, in block 1420, a second identifier is assigned to the balancedata. Since the account data is identified by the first identifier andthe balance data is identified by the second identifier, the associationof the first identifier with the second identifier establishes arelationship between the account and the balance. Thus, the firstidentifier and the second identifier can be stored as a set of data.Consequently, the account data and the balance data are associated so asto relate the account with the balance. Furthermore, this set of datacan be stored on a separate database shown as the account-balancedatabase for establishing the relationships between each account andeach balance that is required by the business for that account.

Product Balance

Referring now to Table G, the relationship between product and balancecan be seen for product balance associative database 150 in FIG. 1A. Theproduct balance association establishes the balances for a given productas well as the terms and conditions for their accumulation. Table Gillustrates that, for a revolving credit type product, four differentbalance types can be utilized. Namely, in the example shown in Table G,balance types of “open to buy”, “cash”, “credit”, and “interest” areestablished. Similarly, the loyalty program product is linked to a“points” type balance and the “checking product” type is linked with atraditional checking balance. The “brokerage product” type is associatedwith a “stock” type balance and the electric utility product is linkedwith a “megawatts used” type balance. The level payment product isassociated with a “payment balance to date” type. TABLE G PRODUCTINTERNAL INTERNAL TYPE PRODUCT ID BALANCE TYPE BALANCE ID RevolvingCredit P0001 Open to Buy B0001 Revolving Credit P0001 Cash B0002Revolving Credit P0001 Credit B0003 Revolving Credit P0001 InterestB0004 Loyalty Program P0002 Points B0005 Checking P0003 Balance B0006Brokerage P0004 Stock B0007 Electric Utility P0005 Mega Watts Used B0008Level Payment P0006 Payment Balance to B0009 Date

Internal identifiers can be used with the product types and balancetypes to identify entries in the product and balance databases. Thus,Table G shows internal product IDs and internal balance IDs. These IDscan be coupled as data entries in the product-balance database. Theentries shown in Table G reflect the data that is associated by groupingthe respective internal product IDs with the internal balance IDs.

Referring now to FIG. 15, a method of implementing the product-balancerelationship can be seen. FIG. 15 illustrates a flowchart 1500 forimplementing a method of establishing a relationship between a productand a balance. In block 1504 of FIG. 15, product data identifying aproduct is stored as an independent set of data. In block 1517, balancedata identifying a balance is stored as an independent set of data. Theproduct data and the balance data can be stored on separate databases,as shown by blocks 1521.

To associate the product data with the balance data, a first identifiercan be assigned to the account data as shown in block 1516. For example,the identifier can be assigned to an entry in the account database afterthe identifier is generated by an internal system identifier generator.Similarly, a second identifier can be assigned to a balance type asshown in block 1520. Then, the product data can be associated with thebalance data so as to relate the product with the balance. This can beaccomplished by associating the first identifier with the secondidentifier as a set of data stored in an account-balance database, forexample.

Party Subject Area

The party subject area, which is a collection of data aboutindividual(s), organization(s), or organization unit(s) needed by aservice provider to carry out business operations on behalf of itselfand/or its client(s) is illustrated in more detail in FIGS. 18, 19A,19B, 19C, 19C1, 19D, 19D1, and 19D2. FIG. 18 illustrates a system 1800having four databases: a party database 1804, an agreement database1812, an agreement-party role database 1816, and a party to partyrelationship database 1808. In this embodiment, the party database 1804is associated with the agreement database 1812 via the agreement partyrole association database 1816. Similarly, the party database 1804 isassociated to itself via a party to party relationship database 1808 andthe party to party relationship database is related to the agreementdatabase 1812. FIGS. 19A, 19B, 19C, 19C1, 19D, 19D1, and 19D2 illustratea more detailed embodiment of these databases as system 1900. In FIG.18, the Party database 1804 and the Agreement database 1812 are coupledwith an Agreement Party Role database 1816. Similarly, the Partydatabase and the Agreement database are also coupled with the Party toParty Relationship database 1808.

A party is an individual, organization, or organization unit that aservice provider needs to have information about in order to carry outbusiness operations on behalf of itself and/or its clients. For example,First Data Resources (FDR), a data processing company in Omaha, Nebr.constitutes a party. Likewise, its parent company First Data Corporationand sister companies such as Western Union or Telecheck are alsoconsidered parties. Client organizations that contract with FDR forprocessing services are also parties. Furthermore, an individual ororganization that is a customer of one of FDR's clients and one of FDR'sclients and who has a role on an account processed by First DataResources is also considered a party. Other examples include partiessuch as a contact person at a merchant organization, a credit bureauthat receives account status information to be incorporated in a creditbureau report, and a vendor that provides plastics.

The party subject area database can store a collection of informationneeded to manage data about individuals and organizations who have adirect or indirect relationship with one another or with a serviceprovider. The party subject area can include information such as:identification data (names, identifiers, biometric information),demographic information, relationships to other individuals, roles onagreements or accounts, and language preferences of the parties.

Organization of the party information can help service providers toaccomplish different tasks, such as: keeping track of their customers,making changes to the party data quickly and easily, managing customerrelationships, and complying with regulations such as recent privacyregulations. Furthermore, from the perspective of a third party dataprocessing provider, such as First Data Resources of Omaha, Nebr. andFirst Data Corporation the organization of the party information canhelp in: responding to changing client needs, providing structures tofacilitate new types of businesses, supporting client defined productswith new types of parties, and supporting new types of partyrelationships, agreements, and roles.

A party is defined within the business context of the entity thatestablishes it. For example, third party processors are capable ofprocessing transactions on accounts for many different banks that offercredit cards. In some cases, a person may have one credit card with BankA and a second credit card with Bank B. In such an instance, that personis recognized by the third party processor as a first entity for Bank Aand a different entity for Bank B. Alternatively, a person may have morethan one credit card issued by the same bank. In that instance, theperson is a single entity used by the processing system to process thedifferent credit card accounts issued by that bank. Thus, for a thirdparty processor that processes transactions for multiple banks, a personcan be represented as different entities—e.g., a different entity foreach bank. Furthermore, for the person who has more than one account ata single bank, a single entity can be used for the party data to processthe transactions—i.e., one entity for multiple accounts.

FIGS. 19A, 19B, 19C, 19C1, 19D, 19D1, and 19D2 illustrate a moredetailed view of the party subject area according to system 1900. First,block 1904 in FIG. 19C illustrates the type of information that can bemaintained about a particular party. For example, a “Party InternalIdentifier” can be generated to identify the entry storing partyinformation for a specific party. Within a data processing systemoperated by a third party processor, for example, the internalidentifier can uniquely identify the party within the context of thedata processor's business operations whereas the “Party ExternalIdentifier” can be assigned by the client to identify the party withinthe context of the client's business operations. In other words, the“Party External Identifier” can be an identifier within the clientorganization as opposed to the internal identifier which is used tointernally track the party entry within the data processing system.Block 1904 also shows that a “Party Classification Type Code” can beassigned to represent the highest level of categorization of the Party.Examples are codes to identify the Party as: an individual, anorganization, or an organizational unit. Further information for anindividual, an organization, and an organization unit can be maintainedas indicated by blocks 1906, 1905, and 1932, respectively.

Block 1906 indicates the type of information or attributes that can bemaintained for an individual. An individual is a person that the systemneeds to have information about in order to carry out businessoperations. For example, the individual's birth date, death certificateidentifier (i.e., an externally defined identifier of the deathcertificate issued by a geopolitical organization to certify the deathof the individual), and date the individual died can be maintained. Incases where the death certificate has not yet been received, anindicator designating whether the individual is dead can be recorded. Inaddition, a code representing the ethnic classification used by anindividual can be recorded, as can an individual gender coderepresenting the sex of the individual (e.g., “male”, “female”, or“Gender not provided”). A code representing the marital status of theindividual can be recorded as part of the entry, as well, such as commonlaw marriage, divorced, separated, head of household, married, domesticpartner, single, widowed, or unknown. In addition, a field can be usedto record the national heritage of an individual, such as German,Italian, Scandinavian, etc. This can be a useful field for applying therequirements of increased government scrutiny of financial accounts,such as the heightened scrutiny applied by the Patriot Act. Theeffective date that the individual becomes eligible for Soldier andSailor Act benefits can be recorded as can an indicator indicatingwhether the individual is currently eligible for benefits under theSoldier Sailor Act. In addition, a code representing a generalcategorization of an individual's citizenship can be recorded, such asthe individual is a US citizen, the individual is not a US citizen, theindividual is a citizen of another country as well as a citizen of theUS, or the individual citizenship is not provided. Also, an indicatorcan be used to designate whether the individual is a veteran of one ofthe military branches. Also, an “Individual Solicitation ProhibitionCode” can be used to indicate whether an individual can be contactedabout purchasing new or additional products. The values for this codemay indicate: 1) Yes, you may solicit and telemarket the customer; 2) Donot solicit this customer; 3) Do not telemarket this customer.

In FIG. 19C 1 block 1905 shows the type of information, in the form ofattributes, that can be maintained for an organization. An organizationis created within the context of the business requirements of the Partythat defines it. For example, in the context of a third party processorsuch as First Data Corporation, an organization could include any FirstData company, such as First Data Merchant Services, Telecheck, andWestern Union; a client organization, such as an issuer bank ABC or anacquirer bank XYZ; a merchant organization (e.g., Mom and Pop's Diner orLarge Retail Conglomerate); a regulatory organization (e.g., Visa,MasterCard, State of Nebraska, or Securities Exchange Commission); athird party organization (e.g., vendor organization, network provider,or credit bureau); or an organizational unit (e.g., a division of anorganization that is not a legal entity in and of itself, such as adivision, department, or branch).

Block 1905 shows examples of attributes that can be stored as part of anentry for an organization. For example, “Organization BusinessDescription Text” can be maintained for use as party-defined textdescribing the nature of the business. Furthermore, an “OrganizationClassification Type Code” can be used to classify the organization asbelonging to a particular class, such as an internal division orsubsidiary of the third party processor (e.g., in the case of First DataCorporation: First Data Corporation, First Data Resources, TeleCheck,and Western Union), a financial institution (e.g., a bank or creditunion), a merchant organization (e.g., a department store, a Mom and Popstore, a mail order company), a regulatory organization (e.g., VISA,MasterCard, IRS, or Federal Reserve), a third party organization (e.g.,a vendor, credit bureau, or law firm), a client organization (e.g., anorganization that can take on the role of Issuer or Acquirer), anindependent sales organization, or a customer organization (e.g., acommercial card customer). Another attribute that can be stored as partof the entry is an “Organization Employee Count” which is a count of thepersons employed in an organization as specified by the Party thatdefined the organization. This field can be used, for example, toprovide a discount rate to employees when the employer has a certainnumber of employees. Other attributes that can be stored as part of anorganization entry include: a code representing the year theorganization was formed; a code representing the month in which theorganization's accounting cycle closes for determining profits or lossesfor the year; a code representing the state in which the organizationwas chartered; a code describing the tax status of the organization forfiling state and federal taxes; a code representing whether theorganization was formed or chartered in the United States; a coderepresenting the legal structure of the organization, or an“Organization Cost Center Identifier” that indicates the accounting areawhere costs for the organization are to be allocated.

Block 1905 shows further sub-blocks which categorize additionalinformation about different types of organizations. For example, block1907 shows data that is specific to a financial institution. A financialinstitution is an organization that collects finds from the public toplace in financial assets. For example, a bank, a savings and loanassociation, a credit union, and an insurance company are examples offinancial institutions. Examples of information that can be stored for afinancial institution include a “Federal Reserve Transit RoutingNumber”, a “Financial Institution Classification Type Code” (e.g.,depository or non-depository institution), and a “Financial InstitutionFDIC Member Indicator” (i.e., designating whether the financialinstitution is a member bank of the FDIC).

Block 1988 shows data that can be maintained for a customerorganization, such as any organization whose primary relationship with athird party processor is as a customer of a client of the third partyprocessor. An example of this is an organization that has a commercialcard agreement with an ABC Bank—where ABC Bank is a client of the thirdparty processor. An example of a code that can be maintained as part ofthe entry for a customer organization is a customer organizationclassification type code that describes the customer as being acommercial card customer, or a fleet customer, etc.

Block 1909 illustrates data can be maintained for a third partyorganization. A third party organization is typically a supplier orservice provider such as a material vendor, an insurance vendor, arewards fulfillment vendor, a software vendor, a hardware vendor, aco-brand partner, an information vendor, a data entry vendor, amarketing vendor, a collection vendor, and a voice response unit supportvendor. As examples of third party organizations, blocks 1910 groupservice provider, block 1911 insurance provider, and block 1913 creditbureau show that data specific to each classification of third partyorganizations can be maintained.

Block 1914 shows that data can be maintained that is specific to a partythat is a client. For example, a “Client Organization ClassificationType Code” can be used to identify the client as an acquirer, an issuer,or both an acquirer and an issuer.

Block 1915 shows that data can be maintained for the data processingcompany's own organizations. In this example, data can be maintainedthat is specific to organizations that are part of First DataCorporation (FDC) entity.

Block 1917 shows that data that is specific to an independent salesorganization can be maintained.

Block 1918 shows that data that is specific to a merchant organizationcan be maintained. A merchant organization can be an organization thataccepts presentation instruments as payment in exchange for goods orservices provided. An example of an attribute that could be maintainedabout a merchant organization is the “Merchant Category Code” thatdesignates the line of business or the type of service that the merchantorganization provides.

Block 1905 also shows that data can be maintained for regulatoryorganizations in block 1919. A regulatory classification type codeattribute is provided to categorize the regulatory organizations. Thetwo example classifications shown in block 1919 are governmentalorganizations and industry associations. In block 1920, shows that a“Governmental Classification Type Code” can be used to classify agovernmental organization, for example, as an internationalorganization, a national organization, a state organization, etc.Likewise a governmental sub-classification code can also be used tofurther categorize the governmental organization. Examples of thesub-classification includes such things as an agency, a bureau, amilitary organization, etc. Similarly, block 1921, association, providesexamples of attributes that can be maintained specifically about anassociation. Examples include such things as an “AssociationIdentifier”, an “Association Name”, and an “Association ClassificationStructure Type Code”.

Block 1982 illustrates how data can be maintained for an organizationunit according to one example. The organization unit is a subset ordivision of an organization as specified by the party that defined it. Asignificant characteristic of an organization unit is that it is notchartered or recognized by any governmental organization as a legalentity and therefore cannot enter into legal contracts. For example, anorganization unit may be a division or department of a legal entity.Another example might be a subset of a merchant organization, such as astore. Attributes can be used to characterize an organization unit. An“Organization Unit Internal Type Code” is a code defined by the dataprocessor that represents the categorization of the organization unit(e.g., business unit, operating division, operations group, division,department, office, client defined). An “Organization Unit External TypeCode” is a code representing the categorization of the organization unitas specified by a party external to the data processor (e.g., a clientdefined code for a business unit, operating division, operations group,division, department, office or branch). An “Organization Unit ExternalIdentifier” is an identifier for the organization unit as specified by aparty external to the data processor (e.g., DIV-01 or DEPT-HR). An“Organization Unit Employee Count” is a count of the persons employed inan organization unit as specified by the party that defined theorganization unit. For example, this field can be used to determinewhether employees of an organization are entitled to get a certaindiscount rate with a partner organization if a minimum number ofemployees are required for the discount to apply. An “Organization UnitEffective Date” can be used to define the date an organization unit isvalid for use within the context of the business of the party thatdefined it (e.g., the date the human resources department is valid in agrowing company that adds a human resources department). Similarly, an“Organization Unit End Date” can be defined to indicate the last datethat the organization unit is valid for use within the context of thebusiness of the party that defined it.

A credit bureau report can be generated for a specific party. Forexample, block 1906 which maintains information for an individual can berelated to credit bureau report Block 1922. The credit bureau reportblock shows that information about the credit history of an individualcan be stored in a database by the system. The credit history isobtained from a credit bureau service provider that gathers theinformation from a variety of sources, such as credit card issuers, homeloan issuers, private label issuers, etc. and produces the report. Thecredit bureau report can detail which lines of credit the Party hasapplied for and received and whether the Party pays their bills in atimely fashion. Attributes can be stored to define the creditinformation. A “Credit Bureau Score Obtained Date” can be used toidentify the date the credit bureau score was obtained from the creditbureau. The “Credit Bureau Derogatory Information Code” can be used toindicate the rating of the derogatory information on file at the creditbureau (e.g., “0” for best rating and “9” for worst rating). A “CreditBureau Number of Trade Lines Code” can be used to indicate the number oftrade lines on file at the credit bureau. A “Credit Bureau Score Number”can be used as a rating derived from the credit information obtainedfrom the Credit Bureau. A “Credit Bureau Worst Public Record Code” canbe used as the rating of the public record on file at the credit bureau.A “Report Bankruptcy Code” can be used to report bankruptcy (e.g.,“-”=chapter 11 bankruptcy; “1”=chapter 7 or 11 bankruptcy; “2”=chapter13 bankruptcy; and “3”=account is seriously delinquent, e.g., sevencycles delinquent). A “Risk predictor Score Number” can be used toassign a client defined risk score. A “Risk Predictor Bureau Identifier”can be used to identify various risk predictor bureaus (e.g., Equifax;Transunion; and =TRW). A “Risk Predictor Model Code” can be used toindicate the credit bureau scoring algorithm used in evaluating acustomer's risk level. “Risk Predictor Score Reason Codes 1-4” can beused to maintain the reason given by the credit bureau for the reportedscore. Also, a “Credit Bureau Report Dispute Code” could be used toidentify the dispute reason on a credit bureau report (e.g., customerrequest or inconsistency).

In FIG. 19B, block 1912 shows the information that can be maintained foran agreement entered into between parties. An agreement is a legal orcontractual arrangement that governs the relationship between two ormore parties. For example, an agreement could be a processing agreementbetween the data processor and one of its clients. Another example of anagreement is a contract between a merchant and its acquirer. Anotherexample is a contract between a Group Service Provider and one of itsclients. Yet another example is a joint venture agreement between two ormore companies. Still another example is a contract between a bankcardissuer and one of its customers. An agreement can be characterized bydifferent attributes. For example, an “Agreement Identifier” can beassigned to an entry in an agreement database in order to identify thecharacteristics of that particular agreement. This can be an internalidentifier defined by the data processor responsible for tracking theagreement information. An “Agreement Classification Type Code” can beused to represent a high level categorization of the agreement (e.g.,partnership agreement, client processing agreement, 3rd party agreement,vendor agreement, employment agreement). An “Agreement ContractualStatus Code” can be used to represent the contractual status of anagreement (e.g., unknown, negotiation in progress, negotiated—butpending signature, signed, expired, terminated, or archived). An“Agreement Effective Date” attribute can be used for the date that anagreement becomes available for use within the context of the businessof the Party who established it. This provides the capability for theParty defining the Agreement to enter information about the Agreementbefore it is finalized. The “Agreement End Date” attribute can be usedto identify the last date that an agreement is available for use withinthe context of the business of the Party who established it. The“Agreement Status Code” attribute is a code representing the status ofthe Agreement at a point in time (e.g., pending, in effect, terminated,or archived). The “Agreement Type Code” attribute is the coderepresenting the specific kind of Agreement (e.g., joint ventureagreement, partner affiliate agreement, issuer processing agreement,rewards fulfillment services agreement, office supplies vendoragreement, or contract employee agreement).

Block 1912 also illustrates how agreements can be further classified bydifferent types. For example, block 1952 shows that credit bureau usageagreement data can be maintained. This is a type of agreement in which aclient of a data processor agrees to use the credit bureau reportingservices provided by a specific credit bureau (e.g., an agreement inwhich an issuing bank agrees to use the credit bureau services of thecredit bureau Equifax). Similarly, block 1953 shows that data for acredit bureau reporting agreement can be used to store data about anagreement between a client of the data processor and a credit bureau inwhich the client has agreed to provide account status information to thecredit bureau. The credit bureau can use this information to buildcredit bureau reports on consumers. For example, this might be anagreement in which the issuing bank agrees to provide account statusinformation to Equifax, the credit bureau. This information is providedto the credit bureau by the data processor of the issuing bank.

Block 1954 shows that the data processor can store settlement agreementdata. A settlement agreement can take the form of a type of agreementthat establishes the terms and conditions under which an organizationacting in the role of processor is able to set up its systeminfrastructure to process settlements for monetary transactionsgenerated using the brand of a specific association. For example, itmight be the agreement by which First Data Resources is able to set upits systems to process MasterCard transactions.

Block 1955 shows that the data processor can store associationmembership agreement data. This is a type of agreement in which afinancial institution becomes a “member bank” of an association.Membership in the association licenses the “member bank” to issue and/oracquire presentation instruments with the network brand of theassociation. The term “member bank” is used in this instance to refer toany financial institution that is a member of the association even if itis not truly a bank, for example a credit union.

Block 1956 shows that data can be stored for a customer agreement. Acustomer agreement is a type of agreement governing the relationshipbetween a client of the data processor and a party that is a customer ofthat client. For example, a credit card agreement establishing anindividual as the primary account holder of a credit card issued by ABCBank which in turn is a client of First Data Resources.

Another type of agreement for which data can be stored is a vendoragreement as shown in block 1957. This is a type of agreement in whichone party (the vendor) supplies a vendor product or service to anotherparty (the purchaser). It may be established directly between a vendorand an organization of the data processor or it may be establishedbetween a vendor and another type of organization, e.g., a clientorganization. For example, it might entail an agreement between aninsurance provider and a client organization to provide life insurancebenefits on a customer agreement. Thus, block 1958 reflects that datafor an insurance agreement can be stored. One example of an insuranceagreement is a type of agreement between two or more parties formed withthe intent to offer insurance products. It is used to define fees,charges, and revenue sharing arrangements.

Block 1959 reflects that data can be stored for a merchant acquireragreement. This is a type of agreement in which an acquiring clientorganization agrees to acquire transactions for a merchant organization.Roles identified for this type of agreement include acquirer, merchant,and association. For example, this could be an agreement in whichFinancial Institution XYZ (the acquirer) agrees to acquire merchant Visa(the association) transactions for Good Food Grocery Store (themerchant).

Another type of agreement is that shown in block 1960 for a partneraffiliate agreement. An example of a partner affiliate agreement mightbe an agreement between an issuer and another organization in which theorganization (i.e., the partner affiliate) gives the customer reward(s)for using the issuer's card when making purchases from the partneraffiliate. For example, this could be an agreement between an issuer andan airline company to provide bonus mileage points when the issuer'scard is used to purchase an airline ticket.

Block 1961 reflects that data for a joint venture agreement can bestored on this type of system. Thus, the system can store data for anagreement by two or more parties to work on a project together. A jointventure may be formed when companies with complementary services wish tocreate product or service.

Block 1962 shows that data can be maintained for an issuer associationagreement. This is a type of agreement in which a financial institutionis licensed as a member bank of an association to issue presentationinstruments with the network brand of the association. For example, thiscould entail an agreement between ABC Bank and Visa USA in which ABCBank as a member bank is licensed to issue Visa credit cards. Or, itcould entail an agreement between XYZ Bank and MasterCard Internationalin which XYZ Bank is licensed to issue MasterCard credit cards.

Block 1963 shows that data can be maintained for a client agreement. Aclient agreement is a type of agreement in which the data processor orone of its subsidiaries contracts with another organization to providethe organization (the client) products or services of the dataprocessor. For example, it might be a contractual agreement betweenFirst Data Resources (a data processor) and Financial Institution ABC toprocess credit cards issued by Financial Institution ABC. Or, it mightbe a contractual agreement between First Data Merchant Services, forexample, and an acquiring bank to process merchant transactionsgenerated by merchant organizations affiliated with the acquiring bank.One type of client agreement is an issuer processing agreement as shownin block 1964. This is a type of agreement in which one organizationoperating in the role of a processor agrees to provide account balanceadministration and/or other processing services for another organizationthat is functioning in the role of an issuer. For example it might be anagreement in which a processor provides account balance administrationfor credit cards issued by ABC financial institution. Or, it might be anagreement in which the processor provides statements for credit cardsissued by XYZ Credit Union (the issuer). Block 1965 indicates data canbe stored for an acquirer processing agreement. This is a type ofagreement in which one organization operating in the role of processoragrees to process transactions for another organization that isfunctioning in the role of an acquirer. Thus, it could be an agreementin which First Data Resources (the processor) processes merchanttransactions acquired by XYZ Financial Institution (the Acquirer).

Block 1966 shows that data can be maintained for an acquirer associationagreement. This can be a type of agreement in which a financialinstitution is licensed as a member bank of an association to acquirepresentation instrument transactions with the network brand of theassociation. For example, this might include an agreement in whichFinancial Institution ABC is established as an Acquirer for VISAtransactions. Or, it might be an agreement in which FinancialInstitution XYZ is established as an acquirer for MasterCardtransactions. Additional attributes for defining acquirer associationagreements can include attributes such as an “Acquirer AssociationAgreement Membership Indicator” and “Acquirer Association AgreementSettlement Indicator”. The “Acquirer Association Agreement MembershipIndicator” designates whether the acquirer has a direct relationshipwith the association. A direct relationship occurs when the acquirer hassigned a legal contract with the association to do business as a memberof the association. An indirect relationship occurs where the acquirerhas signed a legal contract with another institution to present thetransactions to the association on behalf of the acquirer. The otherinstitution will normally have the direct relationship/membership withthe association and the acquirer will have an indirect relationship tothe association. The other attribute shown, the “Acquirer AssociationAgreement Settlement Indicator”, designates whether the acquirer hascontracted with the processor to perform the settlement function formonetary transactions tied to a specific association.

In FIG. 19A, block 1916 illustrates how data can be stored for anagreement party role relationship. It provides a means for identifyingthe various parties to an agreement and the role that each party playson the agreement. An agreement party role may vary based on the type ofagreement, type of party, or other party-defined or agreement-definedcriteria. It represents information about the party in relation to theagreement itself. Block 1916 can pull data from the agreement block 1912and the party block 1904 to create an entry with further informationabout the role played by that party on that agreement. For example, in aprocessing agreement between First Data Resources and ABC Bank, ABC Bankacts in the role of Client (issuer); FDR acts in the role of processor;VISA acts in the association role; Specialty Toys acts as the affiliatepartner; Gift Fulfillment Center acts as the rewards fulfillment party;J. J. Doe acts as the account manager; M. J. Burns acts in the role ofsignature party at FDR; and Mary Jane Moore acts as the signature partyat ABC Bank. Attributes for the agreement party role include “AgreementParty Role Effective Date”; “Agreement Party Role Type Code”; and“Agreement Party Role End Date.” The “Agreement Party Role EffectiveDate” is the date the party begins to function in the agreement partyrole (e.g., the date an organization is added as the rewards fulfillmentparty). The “Agreement Party Role Type Code” represents the role that aparty plays in an agreement (e.g., client, partner, processor,association, etc.). The “Agreement Party Role End Date” attributeindicates the last date that the party functions in the agreement partyrole.

Block 1967 shows that data specific to a merchant role can be maintainedin a database entry. This is the role an organization assumes whenaccepting presentation instruments as payment in exchange for goods orservices provided relative to a specific agreement.

Block 1968 shows that data specific to a processor role can bemaintained in a database entry. This is the role a party assumes whenprocessing information or transactions for another party based on theterms and conditions of an agreement.

Block 1969 shows that data specific to an association can be maintainedin a database entry. This is the role an organization assumes as theregulatory organization governing the use of presentation instrumentsrelative to a specific agreement. For example, this might be informationspecific to an association's role on a specific issuer processingagreement.

Block 1970 shows that data specific to a partner affiliate role can bemaintained in a database entry. This is the role an organization assumeswhen collaborating with another organization for the purpose of offeringmultiple products or services in one medium.

Block 1971 shows that specific to a third party role can be maintainedin a database entry. This is the role a party external to the processoror its clients assumes in providing product(s) and/or service(s) to theprocessor and/or its client(s) relative to a specific client agreementor customer agreement. For example, it might include information about avendor's role in supplying rewards accumulated by a customer on a creditcard account processed by the First Data Resources. Block 1972 furtherreflects data for a purchaser role. Block 1972 purchaser role and block1973 vendor role show examples of the type of third party roles that canbe defined. The purchaser role is the role a party assumes whenpurchasing goods or services from another party via a vendor agreement.Block 1973 reflects data for a vendor role. This is the role a partyassumes on an agreement in supplying or providing a service that iscritical to the fulfillment of a specific agreement. For example, thiscould be the role of an insurance provider for the life insurance on acustomer agreement.

Block 1974 shows that data can be maintained for an expanded cardmerchant party role. This is the role an organization assumes as relatedto a merchant agreement. One attribute that can be used to furtherdefine this role is the Merchant Party Role Type Code. This representsthe role assumed by the organization on a merchant agreement (e.g.,merchant, acquirer (client), system bank, principal bank, agent bank,merchant headquarters, issuer (client)).

Block 1975 shows that data can be maintained for a client role. This isthe role an organization assumes when contracting with a processor likeFirst Data Corporation, for products and/or services via a clientagreement.

Block 1976 shows that data can be maintained for an acquirer role. Thisis the role the client organization assumes by entering into anagreement with a merchant organization to acquire presentationinstrument transactions generated by the merchant organization. Thiscould be information about the role of ABC Bank as the acquirer ofmerchant VISA transactions for XYZ Grocery Store via an acquirermerchant agreement.

Block 1977 shows that data can be maintained for an issuer role. This isthe role a client organization assumes by entering into an agreementwith a party to assume the monetary risk associated with providing theparty a presentation instrument or other financial instrument via acustomer agreement. For example, this could be the information about therole of a bank as issuer of a commercial product on a corporate customeragreement.

Block 1978 shows that data can be maintained for a customer role. Thisis the role an individual or organization assumes on a customeragreement for a product and/or service provided by a client of theprocessor. For example, this could be information about the role of anindividual who has a credit card with an issuer that is a First DataResources client.

Block 1979 shows that data can be maintained for an individual customerrole. This is the role an individual assumes on a customer agreement foran individual product or service provided by a client of the processor.For example, it could be information about the role of an individual whohas a customer agreement for a credit card with an issuer that is aFirst Data Resources client.

Block 1980 shows that data can be stored for a corporate customer role.This is the role an organization assumes in relation to the purchase ofa commercial product or service provided by a third party processor'sclient via a customer agreement. For example, this could be informationabout the role of an organization that purchases a commercial cardproduct offered by an issuer that is an FDR client.

Block 1981 shows that data can be maintained for an applicant role. Thisis the role an individual or organization assumes when applying for aproduct and/or service offered by a client of the third party processor.For example, this could be information about the role of an individualwho applies for a credit card with an issuer that is an FDR client.

In FIG. 19D, block 1908 shows how data can be maintained for a party toparty relationship. A party to party relationship is a direct or anindirect relationship, association, or affiliation between two parties.A direct relationship occurs when the association exists directlybetween the processor and a specific party (e.g., First Data'srelationship with a bank whose credit cards First Data processes). Anindirect relationship occurs when the processor has an association to aparty via that party's association to another party who has a directrelationship with the processor (e.g., First Data's relationship to thecustomer of a bank who is a client of First Data). Other examples ofparty to party relationships are:

-   1) a client relationship between the data processor (e.g., First    Data) and XYZ Credit Union;-   2) a customer relationship between XYZ Credit Union and ABC Company;-   3) a customer relationship between ABC Company and individual J.    Doe;-   4) an employment relationship between XYZ Credit Union and J. Doe;-   5) a third party relationship between the data processor (e.g.,    First Data) and vendor DEF Company;-   6) a partnership relationship between XYZ Credit Union and a    national book store;-   7) a family relationship (e.g., parent to an individual, brother, or    sister to an individual).

At a high level, a party to party relationship can be classified by thetype of parties that participate in the relationship. Some party toparty relationships can only exist between two parties that areindividuals; for example, family or spouse relationships. These arereferred to as individual to individual relationships. They are furtherdescribed in block 1940. Other party to party relationships can onlyexist between two parties that are organizations; for example,subsidiary or holding company relationships. These are referred to asorganization to organization relationships. Sometimes they are alsoreferred to as business to business relationships or B2B relationships.These are depicted in block 1927. Still other party to partyrelationships can only exist when one party is an individual and theother party is an organization. These are classified as individual toorganization relationships and are depicted in block 1923. Examplesinclude relationships such as organization contacts and individualcustomer relationships. Party to party relationships that do not haverestrictions or one or both types of parties are referred to asmulti-typed party to party relationships. Examples include employmentrelationships, customer relationships, and vendor relationships. Theyare depicted in block 1944. In block 1908, the party to party generalclassification type code is the attribute that provides the capabilityto specify this high level categorization of a party to partyrelationship. It also includes values to describe organization toorganization unit relationships and organization unit to organizationunit relationships. It can also be set up to include individual toorganization unit relationships and/or other general relationships.

Block 1908 also shows that a Party to Party RelationshipSub-Classification Type Code can be used to sub-categorize therelationships represented in each of the general classifications. Forexample, an organization to organization relationship might besub-classified as one of the following: an acquirer merchantrelationship, an association member bank relationship, a clientrelationship, a corporate customer relationship, a merchant associationrelationship, an organization legal structure relationship, apartnership relationship, a processor association relationship, etc.Likewise, an individual to individual relationship might besub-classified as an individual contact relationship, a professionalrelationship, a personal relationship, etc. It thus provides a way torepresent the specific kind of relationship that exists between twoparties. For example, this could entail:

-   -   Client Relationship (e.g., ABC Bank is a client of FDR)    -   Customer Relationship (e.g., John Doe is a customer of ABC Bank)    -   Employment Relationship (e.g., John Doe is employed by Great        Foods Grocery Store)    -   Partner Relationship (e.g., Toy Mart is an affiliate partner of        ABC Bank)    -   Third Party Relationship (e.g., ABC Bank has third party        relationship with XYZ Check Printer)    -   Organization Legal Structure (e.g., First Data Resources has an        organizational legal structure relationship with First Data        Corp.)    -   Internal Organization Structure    -   Individual/Family Relationship (e.g., Jane Doe has an individual        or familial relationship with John Doe)    -   Organization Unit Relationship (e.g., Training is a department        in the Human Resources Division).

The “Party to Party Relationship Effective Date” attribute shown inblock 1908 can be used to identify the date the party to partyrelationship is valid for use within the context of the businessoperations of the party that defined it. Similarly, the “Party to PartyRelationship End Date” can be used to identify the last date that theparty to party relationship is valid for use within the context of thebusiness operations of the party that defined it.

The “Party to Party Relationship Participant Classification Code” is theattribute that represents a categorization of the party to partyrelationship based on the type of parties participating in therelationship. Values for this attribute include the following as shownin a format illustrating subject to object:

-   -   Individual to Individual (e.g., for parent of child, or employee        to manager)    -   Individual to Organization (e.g., employee to employer        organization)    -   Individual to Organization Unit (e.g., John Doe to Sales        Department)    -   Organization to Individual (e.g., Bank XYZ to John Doe)    -   Organization to Organization (e.g., First Data Resources to        First Data Corp.)    -   Organization to Organization Unit (e.g., ABC Credit Bureau to        ABC Credit Bureau Western Region)    -   Organization Unit to Individual (e.g., XYZ Law Firm to Jane Doe        receptionist)    -   Organization Unit to Organization (e.g., Sales Dept. to Int'l.        Trucking Co.)    -   Organization Unit to Organization Unit (e.g., Sales Dept. to        Human Resources Dept.)    -   Party to Party.

The “Party to Party Direct Relationship Indicator” attribute designateswhether the service provider views the party to party relationship as adirect relationship to itself. If the relationship is a “direct”relationship, the service provider processor is a party to therelationship and/or the agreement that established it. If therelationship is an “indirect” relationship, the processor is not a partyto the relationship. In the case of an “indirect” relationship, theprocessor has knowledge of the relationship because it is needed to doprocessing on behalf of the service provider.

Block 1923 shows that data can be stored for an individual toorganization relationship. This is a type of party to party relationshipthat represents a relationship between an individual and anorganization. Knowledge of this relationship can be used by a serviceprovider to carry out business operations for itself or on behalf of itsclients. An “Individual to Organization Relationship Classification TypeCode” can be used to represent a high level of categorization of thetype of relationship that exists between an individual and anorganization. Block 1924 shows that data can be maintained for anorganization contact relationship. This is a type of party to partyrelationship in which an individual serves as a business contact for anorganization. Block 1925 illustrates that data can also be maintainedfor an individual customer relationship. This is a type of party toparty relationship that represents the business relationship establishedby an individual with a client of the data processor for products orservices offered by the client organization.

Block 1926 shows that data can be maintained for a customerrelationship. This is a type of party to party relationship thatrepresents a business relationship established by an individual ororganization with a client of the service provider, in the case of athird party processor, or the service provider themselves, for productsor services.

Block 1927 shows that data can be maintained for an organization toorganization relationship. This is a type of party to party relationshipthat represents a business to business relationship. For example itcould be a partnership relationship between two organizations. Thisinformation can be used by the service provider to carry out businessoperations for itself or on behalf of its clients. As shown in block1928, a corporate customer relationship is one type of organization toorganization relationship. A corporate customer relationship is a typeof party to party relationship that represents the business relationshipestablished when an organization contracts with a service provider forcommercial products or services offered by the service provider or aclient of the service provider as in the case of a third partyprocessor. Block 1929 shows an acquirer merchant relationship. This is atype of party to party relationship that identifies a merchantorganization as a merchant acting in the role of the acquirer of creditcard transactions. Block 1930 shows a merchant association relationship.This is a type of party to party relationship in which a merchantorganization establishes a relationship with an association to acceptpresentation instruments that use the network brand of the association.

Block 1931 shows that data can be maintained for an organization's legalstructure relationship. This is a type of party to party relationshipthat represents the legal relationship that exists between twoorganizations based on their organizational structure as chartered orfiled with a governmental organization (e.g., a relationship between aparent company and a subsidiary company). Block 1932 illustrates thatdata is maintained for a client relationship. This is a type of party toparty relationship that represents a direct business relationshipestablished by an organization with the data processor (or one of itssubsidiaries) via a contractual agreement for products or services ofthe data processor (e.g., the client relationship between FDR and ABCBank (an issuer) for FDR to process credit line accounts issued by ABCBank).

Block 1933 shows that data can be maintained for an association memberbank relationship. This is a type of party to party relationship thatrepresents a financial institution's participation as a member in anassociation. Furthermore, block 1934 shows that data can be maintainedfor an acquirer association relationship. This is a type of party toparty relationship established between an acquirer and an association.Similarly, block 1935 shows that data can be maintained for an issuerassociation relationship. This is a type of party to party relationshipestablished between an issuer and an association.

Another type of organization to organization relationship is apartnership relationship shown in block 1936. This is a type of party toparty relationship that represents the business relationship establishedwhen one organization collaborates with another organization in businessaccording to the terms and conditions of a partnership agreement.

Block 1938 shows that data can be maintained for an organization toorganization unit relationship. This is a type of party to partyrelationship that represents relationships between an organization andan organization unit. Knowledge of this relationship can be utilized bythe service provider to carry out business operations for itself or onbehalf of its clients, as in the case of a third party processor.

Block 1939 shows that data can be maintained for an organization unitrelationship. This is a relationship, association, or affiliationbetween two organization units within the same organization. Knowledgeof this relationship is used by the data processor to carry out businessoperations for itself or on behalf of its clients. Although thisrelationship could be used to establish non-hierarchical relationshipsbetween the organizational units, it can be used to define hierarchicalrelationships between them, e.g., levels within the organization.

Block 1940 shows that data can be maintained for an individual toindividual relationship. This is a type of party to party relationshipthat represents an individual, familial, or professional relationshipbetween two individuals. Knowledge of this relationship is useful to theservice provider to carry out business operations for itself or onbehalf of its clients, as in the case of a third party processor. Block1941 shows an individual contact relationship. This is a type of partyto party relationship in which one individual functions as a contactperson for another individual. For example, Don Jones is an emergencycontact for Mary Smith. The professional relationship shown in block1942 is a type of party to party relationship in which the twoindividuals have a business or professional relationship, e.g.,doctor/patient or attorney/client. The personal relationship of block1943 is a type of party to party relationship in which one individualhas a personal or familial relationship with another individual, e.g.,John Doe is married to Mary Doe.

Block 1944 shows that data can be maintained for multi-typed party toparty relationships. This is a type of party to party relationship thatis not restricted to two single participant types. For example, anemployment relationship—the employer could be an individual or anorganization. Types of multi-typed party to party relationships caninclude a third party relationship, a customer relationship, and anemployment relationship.

Block 1945 shows that data can be maintained for a third partyrelationship. This is a type of party to party relationship that existsbetween the service provider and/or a client of the service provider, asin the case of a third party processor, and another party that iscritical to the business operations of the service provider. One exampleof this is a vendor relationship as shown in block 1946. A vendorrelationship is a type of party to party relationship established via avendor agreement. It may be established directly between a vendor and anorganization of the data processor or it may be established between avendor and another type of organization (e.g., with a clientorganization). Block 1947 shows data for a customer relationship. Thisis a type of party to party relationship that represents a businessrelationship established by an individual or organization with a clientof a data processor for products or services offered by the clientorganization.

Block 1948 shows that data can be maintained for an employmentrelationship. This is a type of party to party relationship in which anindividual is employed by another individual, organization, ororganizational unit, e.g., Jane Doe is an employee of Mary Jones. Typesof employment relationships can include an individual employeerelationship, a contract employee relationship, or a corporate employeerelationship. The individual employee relationship is shown by block1949. This is a type of party to party relationship in which oneindividual works for another individual for compensation. Block 1950illustrates a contract employee relationship, which is a type of partyto party relationship in which an individual is hired by an individual,organization, or organization unit as a consultant or contractor insteadof as an employee. Finally, block 1951 illustrates a corporate employeerelationship. This is a type of party to party relationship in which anindividual is employed by an organization or organization unit.

Account Subject Area

A more detailed view of the account subject area can be seen byreference to FIGS. 2020A, 20B, and 20C which show an example of anaccount system 2000. In system 2000, an account database 2004 is used tostore data for a plurality of different accounts managed by a serviceprovider. An account can be understood to be a mechanism used to record,measure, and/or track financial and/or non-financial information relatedto a contractual agreement.

An entry can be established for each account managed by a serviceprovider which is stored in the database 2004. For the service providerto keep track of each account that it deals with, an identifier can begenerated to identify each particular account. In the case of an accountmanaged by the service provider, an account internal identifier can begenerated.

In addition to the “Account Internal Identifier” used to identify eachaccount entry, additional information can be stored for each accountmanaged by the service provider. For example, an “Account ClientIdentifier” can be stored as part of the entry. This attributeidentifies which client of the service provider issued the account. Forexample, it could identify an account as a Bank One credit card account.Another data attribute that can be used as part of the account entrycould be an “Account Client Controlled Identifier” which allows theclient to assign their own identifier for the account which is uniquewithin the context of that specific client's portfolio. Yet another dataattribute that can be used as part of the entry is an “AccountAuthorization Prohibited Indicator”, so as to indicate whetherauthorization is prohibited for the account. Similarly, an “AccountBankruptcy Indicator” code can be used as part of the entry to indicatewhether the account is associated with a bankruptcy proceeding. Anothercode that can be used is an “Account Charged Off Indicator”. This codecan be used to indicate whether the account has been charged off.

An “Account Credit Balance Indicator” can be used as part of the datastored in an account database to indicate whether the account has acredit balance. Similarly, an “Account Delinquent Balance Indicator” canbe used to indicate whether the party associated with the account isdelinquent in some manner. Also, an “Account Frozen Indicator” can beassociated as part of the entry to indicate whether the account has beenfrozen by the service provider, the client of the data processor, or agovernment authority. The “Account Open Indicator” can be used toindicate whether the account is open or closed. Furthermore, the“Account Original Open Date” can be used to indicate when the accountwas originally opened. The “Account Overlimit Balance Indicator” can beused to indicate whether the account balance is overlimit. This could beused for example in the case of a credit card account.

The “Account Revoked Indicator” can be used as part of the account entryto indicate whether the account has been revoked. Furthermore, the“Close Inactive Account Code” can be used to indicate whether aninactive account is closed or is to be closed. Other codes can be usedas well to characterize the account. However, it is not necessary thatall of the above attributes be used for any particular account. Rather,some attributes may lend themselves to use by special sub-types ofaccounts.

Block diagram 2000 shows examples of a variety of accounts that can beused under the system. For example, block 2012 indicates that data for acredit line account can be managed. A credit line account is a type ofaccount based on an agreement for a financial institution to provide acustomer with an open-ended line of credit that may be used repeatedly(e.g., revolves) up to a certain limit. Examples of credit line accountsare a commercial card account, an oil account, and a retail account.Another type of account is a loan account 2013. A loan account is a typeof account that is established for a loan or a closed-end credit saleagreement in which the amounts advanced, plus any finance charges, areexpected to be repaid in full over a definite period of time. Examplesof a loan account are a property loan account and a vehicle loanaccount. Another type of account is a PI acceptor account as shown inblock 2014. This is a type of account is based on an agreement toprovide acquiring services for a Merchant. Other types of accountinclude a check verification account 2015, a transfer account 2016, anda suspense account 2017. A transfer account is a type of account that isestablished to record a request for and the completion of a transfer ofan item of monetary value between two points. A suspense account is anaccount created to manage transactions that need to be evaluated forfraud before allocating to an account balance.

Also shown in system 2000 are types of commercial card accounts, such asfleet account 2018, purchasing account 2019, travel and expense account2020, individual bill account, 2021, consolidated bill account 2099,control account 2022, and sub account 2023.

Yet another type of account shown in system 2000 is service account2024. A service account can be a type of account that is based on anagreement for a non-financial product. Examples shown for the serviceaccount are lease account, reservation account, telecom account, cellphone account, transit account, and utility account.

Still another type of account is the insurance account 2026. Aninsurance account is a type of account based on an agreement betweenparties whereby in return for payment of premiums, one party willcompensate the other party for (generally unexpected) losses. Examplesof insurance accounts are a health policy account, a life insuranceaccount, and a property and casualty account.

The final example of a type of account shown in system 2000 is a depositaccount 2025. A deposit account is a type of account based on anagreement for a product that is funded by customer deposits. Examples ofdeposit accounts are a demand deposit account, an investment account, aloyalty program account, a prepaid account, a savings account, and a PIliability account (e.g., a PI liability account could be an account setup by an organization to track its liability for one or morepresentation instruments whose values are not tied to a particularcustomer account or an account party relationship).

In FIG. 20B, blocks 2004 and 2028, illustrate how an account to accountrelationship can be established. The account block 2004 reflects thatdata can be stored as an entry for each specific account. The accountentries defined by block 2004 are considered internal accounts in thatthey are accounts managed by a service provider for clients or in thecase of a company acting as a service provider itself, the accounts arethe company's own accounts. A relationship between two internal accountsor an internal account and an external account can be established bypulling an account identifier for a first account, pulling an accountidentifier for a second account, and assigning those two identifiers an“Account to Account Relationship Type Code” as a new association inblock 2028. The “Account To Account Relationship Type Code” identifiesthe type of relationship that exists between the two accounts. It isgenerally preferable to designate one of the accounts, such as the firstaccount, as being the primary participant in the relationship anddesignating the remaining account as the secondary participant. Thus,for example, in the case of an account diversion, the system willunderstand which account to divert the transactions from and whichaccount to post the transactions to.

An account to account relationship can be further defined by an “Accountto Account Relationship Effective Date” and an “Account to AccountRelationship End Date”. This allows the entry for the relationship todefine when the relationship is in effect and when it is not in effect.

Examples of account to account relationships that can be identified bythe account to account relationship type code are shown in block 2028 asaccount diversion, account transfer, and account reserve depositaccount. These types of accounts can be further defined by additionalattributes. For example, the account diversion relationship can befurther described by an “Account Diversion Default Code”. Similarly, theaccount transfer relationship can be further described by an “AccountTransfer Forward Posting Indicator”.

The account to account relationship entries can be operated on by abusiness rules database to execute the actions of each relationship. Forexample, at the appropriate time, the business rules can access theaccount diversion entries and identify the account to which the postingof individual transactions are posted. These business rules alsoindicate whether or not it is appropriate to post a given transaction toboth accounts in the relationship.

Block 2030 illustrates how multiple accounts can be bundled together forpurposes of account portfolio securitization. This allows formation of agroup of accounts bundled or pooled together in the form of a bond. The“Account Internal Identifiers” are associated with an “Account PortfolioSecuritization Identifier” so as to identify the bundle of accounts.Furthermore, an “Account Portfolio Securitization Pooling DescriptionText” can be used as an attribute for the entry that is created.

The account database can also be used to facilitate account groups asshown in the account group block 2034. An account group is a collectionof accounts created so that they can be treated or processed as a group.System 2000 shows a financial institution, such as one of the serviceprovider's clients as establishing the account group. An “Account GroupIdentifier” is generated by the service provider so that the serviceprovider can identify the account group internally. Furthermore,additional attributes can be associated with each account group, such asan “Account Group Type Code” to identify a specific category of accountgroups. Another attribute that might be included is an “Account GroupDescription Text” attribute.

Examples of account groups shown in block 2034 are an account householdgroup, an account management group, an account report group, an assetmanagement account group, and a commercial card account group. Anaccount household group can be, for example, an account group composedof some or all of the accounts belonging to individuals in a singlehousehold. An account management group can be a set of accounts thathave selected properties maintained and/or general business processesinvoked as a group. An account report group can be a type of accountgroup created so that accounts can be attached and reported as a group.An asset management account group can be a type of account group createdso that accounts of different account types belonging to one party canbe reported as a group. A commercial card account group could be agrouping of accounts created to assist an organization in managing theirspending.

Block 2040 illustrates one way in which accounts can be assigned to anaccount group. In block 2040, an “Account Internal Identifier” isretrieved from the account database represented by account block 2004and associated with an “Account Group Identifier” from the account groupdatabase block 2034. In addition to the attributes, additionalattributes can be assigned, such as a start date, an end date, anoverride indicator, and a role code.

Block 2048 illustrates how one can define accounts that qualify to be inone of the types of accounts shown in block 2034. Thus, qualificationcriteria represented by, for example, “Account Group Qualification ValueText”, “Account Group Qualification Percent Rate”, and “Account GroupQualification Maximum Number” can be used as qualification criteria todetermine which accounts are to be added or removed from a particularaccount group. These criteria can be acted upon by business rules todetermine the accounts that satisfy the criteria or that do not satisfythe criteria.

Block 2044 indicates that account groups themselves can be grouped assuper groups of accounts. This is accomplished by building groupscomposed of established groups. Thus, for example, all the commercialcard accounts in Omaha, Nebr. for Bank ABC can be grouped as one accountgroup. Furthermore, all the commercial card accounts in Nebraska forBank ABC can be grouped by grouping all the lower level groups, such asthe previously established group of accounts in Omaha for Bank ABC. Thisgrouping of other groups can be given an “Account Group Structure LevelName”.

Also shown in system 2000 is a collateral block 2008. The system can beconfigured to associate a piece of collateral with an account. Thuscodes can be assigned to identify the collateral and link it with an“Account Internal Identifier” for an account.

Similarly, block 2027 shows a block indicating Fraud/Collections. Thisblock allows the system to perform fraud monitoring and collectionservices. A particular account can be linked by “Account InternalIdentifier” with a case queue that allows the case to be operated on bya fraud investigator or collection agent.

Transaction Subject Area

A transaction is a collection of data about business actions or eventsthat impact implied financial worth, cause movement of finds from oneaccount to another, and/or impact non-financial properties (e.g., names,addresses, requests for new plastics). It can include data used for themanagement, administration, and tracking of these transactions fromtheir point of origin through the final settlement, publication, orcompletion of the action or event. A more detailed view of thetransaction subject area can be seen by referring to FIGS. 21A, 21B and21C which illustrate a system 2100 for implementing the transactionsystem.

System 2100 shows transaction block 2104 for storing various types oftransactions. Each transaction can be identified by a unique internaltransaction identifier. This is an identifier that can be generated bythe service provider's data processing system and assigned to the datafor the transaction so as to form a transaction entry. The internalidentifier allows the data processor to track and utilize thetransaction entry. Thus, for example, the internal transactionidentifier can be stored as part of each database entry.

Different types of transactions can be stored by the transactiondatabase. Each of the transaction sub-types will have attributes whichare common (i.e., the Transaction Internal Identifier) and may haveattributes which are unique to the transaction type. System 2100 (FIG.21A) illustrates a few examples. For example, data for financialtransactions can be stored, as illustrated by block 2108. A financialtransaction is a business action or event that changes implied financialworth and/or results in the movement of funds from one account toanother. Financial transactions can be further sub-typed, as shown inFIG. 21B. Block 2109 indicates that transaction information for a salecan be stored. Block 2174 indicates that transaction data for anauthorization can be stored. Block 2110 indicates that transactioninformation for a cash advance can be stored. Block 2111 indicates thatdata for an adjustment can be stored. Block 2112 indicates that data fora refund can be stored. Similarly, block 2113 indicates that data for areversal can be stored. Block 2116 indicates that transaction data for achargeback can be stored. Similarly, block 2117 indicates that data fora chargeoff can be stored. Block 2115 indicates that transaction datafor a return can be stored. Block 2114 shows that transaction data forother external transactions can be stored as well.

Furthermore, block 2118 indicates that data for an allocationtransaction can be stored. Block 2119 indicates that data for a paymenttransaction can be stored and block 2120 indicates that data for a fundstransfer can be stored. In addition, block 2121 indicates that data foran assessment transaction can be stored which may have two or moresub-types, such as a fee assessment in block 2122 or an interestassessment in block 2123. Furthermore, block 2124 indicates that datafor other internal transactions can be stored.

Block 2125 (FIG. 21A) shows another possible sub-type of transaction asnon-financial transactions which can be stored in the transactiondatabase, as well. A non-financial transaction is the recording of abusiness action or event that changes properties that do not impactfinancial worth or movement of funds. For example, such non-financialtransactions might include changes to names or addresses that arerelevant to communication point information. Another example, is atransaction relating to the ordering of a plastic.

Block 2130 (FIG. 21A) shows how the transaction information can berelated to one another. For example, if two transactions exist in whichthe first transaction is a sale and a second transaction is a return forthe sale, the two transactions can be related by block 2130. This can beaccomplished by retrieving the internal transaction identifier for thesale transaction and retrieving the internal transaction identifier forthe return transaction and associating them as part of a new entry inthe Transaction Relationship database. Furthermore, a “TransactionRelationship Type Code” can be assigned with the two identifiers, aswell, in order to identify the type of relationship that exists betweenthe two transactions. Thus, for example the internal transaction for thesale can be retrieved and the internal transaction identifier for thereturn can be retrieved so as to allow both identifiers to be stored asa new entry in block 2130 along with a type code identifying therelationship as a return on the sale.

By relating the various transactions in this way, a large amount of datastorage can be saved as well as a significant amount of processing time.Instead of creating a master record that includes every possible type ofrelationship between two transactions, the transaction entries can bekept quite simple. Then, by virtue of the transaction relationshipdatabase, the history of the transaction can be tracked. Since not allsales will be reversed, it would be a waste of data storage to create anentry for every sale that provides the option of indicating whether thesale was reversed. Rather, the sale transaction can be associated to thereversal transaction via the transaction relationship database—insteadof creating a larger master record with unused fields as in existingsystems using static file structures.

By repeatedly querying the transaction relationship database, one cantrack the lineage of a transaction's relationships. For example, for asale, the original sale can be associated to a chargeback transaction.Similarly, the chargeback can be queried from the transactionrelationship database to show that the chargeback is related to the saleas well as a reversal transaction. Thus, a service provider can obtainthe successive transactions that originate from the originaltransaction, or vice versa, by repeatedly querying the transactionrelationship database to acquire the next step in the lineage.

Block 2156 (FIG. 21C) shows how data for a transaction addendum can bestored. A transaction addendum is additional data that supports afinancial transaction. This might be additional information that aservice provider or client of a service provider wants to have trackedor added on to their transactions. For example, this might includeadditional data that contains fleet information about the use of avehicle. Thus, in addition to storing data relating to transactions forthe purchase of gasoline, the information from transactions for theservice or maintenance of vehicles can be stored, as well. Similarly, ifone purchases gasoline at a convenience store, the information aboutfood items purchased with the gasoline can be stored as an addendumentry. Transaction addendums can be recorded for a variety oftransactions. For example, block 2156 shows that transaction addendumdata can be stored for fleet addendums 2157, travel addendums 2158,lodging addendums 2159, retail addendums 2160, vehicle rental addendums2161, and purchase card addendums 2162.

Yet another level of detail can be provided for each of these examplesof transaction addendums by storing another level of detail for eachtransaction addendum, as shown in block 2164 labeled the transactionaddendum detail item. For example, a greater level of detail can berecorded for a particular item bought at a convenience store as part ofthe fleet addendum item block 2165. As another example, for a traveladdendum, transaction information can be stored for a particular leg ofa trip as part of a travel leg addendum item in block 2166. Similarly,data can be stored for a retail addendum item in block 2167 or for apurchase card addendum item in block 2168.

Block 2140 illustrates how data for the status of a transaction can bemaintained and tracked. A transaction status is the state or conditionof a transaction at a particular point in time. For example, a generaltransaction can be presented, rejected, posted, outstanding, unmatched,settled, charged off, cancelled, suspended, or distributed. Similarly,an authorization transaction can be requested, received, approved,declined, transferred, matched, not matched, archived, or cancelled.Depending on the point in time, the transaction will have a differentstatus. Thus, block 2140 provides a mechanism to assign the status of atransaction at different points in time. This can be accomplished byretrieving the internal transaction identifier assigned to a transactionentry from block 2104 and associating it with a transaction status code.The transaction status code will identify the status of the transaction.The internal transaction identifier and the transaction status code canbe stored together in a transaction status database. Additionalattributes can be stored as part of the transaction status entry, aswell. For example, a “Transaction Status Timestamp” can be stored aspart of the entry for the transaction to generally indicate the point intime that the transaction achieved the status represented by thetransaction status code.

Block 2150 shows a mechanism for recording further information for atransaction status. Namely, a “Transaction Status Reason Code” can bemaintained about a transaction status entry. The transaction statusreason code can be used to indicate the reason why a transaction wasplaced in a certain state. Thus, a transaction status reason entry canbe stored in the database represented by block 2150. In addition, anattribute on the transaction status reason database can be used to storetransaction status reason description text. This descriptive textattribute can be used to store information describing in more detail thereason why the transaction was placed in a particular status.

Block 2170 shows how format specification data for a transaction entrycan be stored. The format data describes the format of an incoming oroutgoing transaction. It can do this using a “Transaction Format TypeCode”. Thus, an internal transaction identifier can be retrieved fromthe transaction database and assigned a transaction format type code.The transaction format type code can be assigned to any one of manydifferent types of formats. For example, the format code could indicatethat the transaction is stored in International Standards Organization(ISO) format. Or, the format code could indicate that the transaction isstored in MasterCard, VISA, or American Express format for thoserespective types of transactions. Similarly, the format code couldindicate an internal format used by the service provider. In the case ofFirst Data Resources, for example, this might be an internal First Dataformat. Alternatively, the format code might indicate a differentprivate label format that can be specified by one of the serviceprovider's clients, as in the case of a third party processor.

Block 2171 shows that the data for the different formats can be storedas individual entries. Thus, block 2171 can store the data definingdifferent types of codes while block 2170 can be used to associate eachcode with a particular transaction entry. This also allows a singletransaction to be manipulated so that it can be used in differentformats. Thus, a service provider might choose to store a transaction ina format as required by one of the merchant organizations and then storethe transaction that is more logical to the service provider's dataprocessing system. This allows the service provider to maintain thetransaction data in the format required by the merchant organizationwhile also allowing the service provider to use the same transactiondata in a format that is more readily accessible by the serviceprovider's internal systems.

The transaction information stored in block 2104 will ultimately need tobe routed to other locations within the system or to external systems.For example, a transaction for a retail sale can be routed to thebalance administration site. Or, an address change transaction can berouted to the communication point site. Similarly, inbound retrievalrequest can be routed to chargeback/return site. This can beaccomplished by associating a functional module message format as shownin block 2135 with a transaction internal identifier from block 2104.The coupling of the functional module message format and the transactioninternal identifier can be stored in the transaction routing rule block2134 as a transaction routing rule definition. Thus, this provides anassociation that describes for a transaction and a functional modulemessage format the formats and attributes required for routing amessage.

Block 2154 illustrates how batch information for performing batchprocessing of transactions can be implemented. This database storesinformation about a non-interactive process in which multipletransactions are bundled together and submitted for processing as awhole. The batch process can be defined through different attributeswhich are grouped with a “Transaction Batch Identifier”. Thistransaction batch identifier can then be retrieved from block 2154 andassigned to each of the individual entries in block 2104. This allowsthe same batch process to be assigned to many different transactions indatabase 2104.

Product Subject Area

One of the disadvantages of prior data processing systems implemented bydata processors on behalf of their clients has been the inability of theclients to use the data processing system to design products accordingto each client's own specifications. Rather, clients have been requiredto work with set terms and conditions in many instances that prevent theclient from tailoring a product to the client's desired configuration.According to one embodiment of the invention, the product subject areaof the data processing system described herein can be used to allowclients to design a new product with a great deal of flexibility.Furthermore, according to one embodiment of the invention, the sameproduct system can be used to design products for different clientsacross a wide range of product lines.

FIG. 22 illustrates a system 2200 for implementing the product subjectarea. It should be understood that a product is a named specificationfor an item or service intended for sale by one party to another partyfor the purpose of generating revenue. System 2200 shows box 2224 asstoring information for different product lines. A product line can be acategory of products that are defined by the data processor according toa business function or business need that the product addresses. Forexample, services for providing lines of credit, such as credit cardservices, are considered a product line. Similarly, insurance isconsidered a product line. Healthcare is another example of a productline.

Data defining each product line can be stored in a database as a productline entry. Thus, an internal identifier can be generated by the serviceprovider and assigned to data defining a particular product line. Theinternal identifier can be referred to as the product line identifierand assigned to a set of attributes so as to create the product lineentry. For example, a product line description text attribute can beused to hold text that describes a particular product line. Similarly, aproduct line name attribute can be used to assign a name to each entrythat serves as a shorthand reference for the product line.

Product lines can be categorized with more particularity through the useof product classifications. A product classification is asub-classification of the product line and can be defined by the serviceprovider. For example, if the product line is telecom, one productclassification can be domestic cellular types of products, while anotherproduct classification can be broadband types of products. A thirdproduct classification can be long distance telecom products. Each aresub-classifications within the telecom product line. To create a productclassification entry, an internal “Product Classification Identifier” isgenerated by the service provider. This can be a simple coderecognizable by the data processor for conducting internal processing bythe service provider. Also, a “Product Classification Description Text”attribute can be associated with the product classification identifierso as to describe in more particularity the product classification.Similarly, a “Product Classification Name” attribute can be assigned tothe entry as a way of easily recognizing the product classification bythe service provider. Furthermore, the “Product Line Identifier” towhich the product classification applies can be included as part of thedatabase entry. Multiple product classifications can likely be createdfor individual product lines.

System 2200 illustrates a block 2204 for storing information for a dataelement. A data element is an elementary type of information that can beused to define a parameter of a potential product being offered by aservice provider (or by a third party data processor acting in the modeof a service provider). The data element can be defined by a third partydata processor—in which case it would be a processor defined dataelement. It can also be defined by the service provider—in which case itwould be considered a service provider defined data element. Examples ofa data element are a VIP Indicator for a credit card account or anAnnual Fee Amount for a service agreement. Typically, the data elementswill be given generic names so that they can be used in a variety ofdifferent product lines. Thus, a data element for a Customer Name canapply to a customer of a restaurant, a client of a law firm, a patientof a doctor, a lessee of an apartment complex, and an insured of aninsurance company, as well as others. Thus, the generic title CustomerName can be used to describe the data element without being specific toany one of those industries.

Policies can also be stored by the data processing system. A policydefines a rule or behavior for a product. For example, it can be used todefine an annual fee policy for an account. Thus, it describes how theproduct's policies will be implemented. Block 2208 is where policies arestored. Each entry for a policy can be assigned an internal policyidentifier and policy name. As was the case for data elements, policiescan also be generic so that they apply to many different productswithout being limited to any specific industry.

While data elements and policies may be recognizable by the informationtechnologists which works frequently in inputting and defining the dataelements and policies, they may not be so readily understandable by aservice provider using the data processing system. Since one embodimentof the invention will allow the service provider to create their ownproduct specifications using the data processing system, the names ofthe data elements and policies need to be more readily understood by aspecific service provider. Thus, block 2212 can be used to allow theservice provider to assign more product line specific names to aparticular data element or policy. This can be accomplished bygenerating an internal “Component Identifier” for each component entry.This allows a component entry to be accessed and identified by the dataprocessing system. The “Data Element Identifier” can be retrieved fromthe data element database in 2204 and associated with the componentidentifier. Furthermore, a more user-friendly component name can beassigned as the component name attribute and associated with thecomponent identifier as an entry in the component database 2212. Thisallows the service provider to assign names to individual data elementsthat can be understood more readily by their business users when workingwith the system. For example, in the case of the data element CustomerName, this data element can be assigned the title Patient Name so that ahealthcare client designing a product can readily recognize the dataelement—since people in the healthcare industry tend to think in termsof patients as opposed to clients or customers.

Thus, a single data element can be associated with many differentcomponents. Again, in the case of the data element Customer Name, afirst component entry could be stored with the component name of PatientName, a second component entry could be stored with the component nameof Lessee Name, and a third component entry could be stored with thecomponent name of Insured Name. While each component entry would havethe same underlying characteristics, it would be referred to by a namethat the industry specific business users of the service provider couldunderstand when designing the product for a particular industry. Thisapplies to policies, as well. Policies can be associated with manydifferent entries in the component database so as to allow each policyto be renamed in a way which makes them more readily recognizable bysomeone who is familiar with a particular industry, product line, orproduct classification.

In addition to renaming data elements and policies by creating entriesin the component database 2212, one embodiment of the system provides afurther degree of definition. Namely, block 2216 illustrates that acomponent can be associated with a product classification. This isuseful in that it allows the data processor to create a subset ofcomponents that are often used in developing a product for a certainproduct classification. For example, anytime a service provider desiresto develop a MasterCard credit card product, a core set of componentscan be quickly identified by the technology staff that will be used bythe business users of the service provider in developing that product.To implement this embodiment of the invention, the service provider canretrieve the “Product Classification Identifier” for a particularproduct classification and retrieve a “Component Identifier” from thecomponent database. The service provider can then save these together asan entry in the database represented by block 2216 and assign a “ProductClassification Component Identifier”. The “Product ClassificationComponent Identifier” is an internal identifier that can be generated bythe service provider to allow the data processing system to process oridentify the entries stored on the processing system. Block 2216 is thususeful in assisting the service provider to easily access thosecomponents that are relevant to a specific product line orclassification.

The development of a product can begin by the service provider that usesthe data processing system, identifying a product that they would liketo develop. This information can then be stored in block 2232. Block2232 shows that a product can be comprised of different attributes. Forexample, a “Product Identifier” can be generated by the data processingsystem or so as to allow the product entry to be easily identified bythe processing system. This internal “Product Identifier” can beassociated with attributes like a product name, such as “Bank ABC VisaGold Card Credit Line.” Furthermore, “Product Description Text” can beused to further define the product with text.

In some instances, one might choose to further define the product with aproduct version. This would allow the service provider to design severalsimilar products and market them on a trial basis. The various terms andconditions or characteristics of the product would vary—typically, theywould vary only slightly—and the service provider could thus offer theproduct versions on a test basis before settling on the desired version.Block 2236 shows how this could be implemented. For example, the“product Identifier” from database 2232 could be associated with a“Product Version Identifier”. This association could be stored on thedatabase represented by block 2236. The “Product Version Identifier”would be an internal identifier generated by the data processing systemfor use in retrieving a specific version of a product. Additionalattributes that could be stored on the product version database include:“Product Version Description Text”, “Product Version Effective Date”,and “Product Version Expiration Date”. The “Product Version DescriptionText” allows one to further describe the version by storing a textualdescription. The “Product Version Effective Date” and “Product VersionExpiration Date” allow the client to define when the version will be ineffect.

To develop a product, the service provider is allowed to select thecomponents (i.e., data elements and policies) that are needed to definethe product. This can be done in a variety of ways. For example, thedata processing system could present all of the possible components forviewing by the service provider. This would likely be an overwhelmingamount of data. Therefore, the service provider might make use of theproduct classification system and retrieve only those components thathave been associated with a particular product classification as shownin block 2216. This would allow the data processing system to retrieveonly those components that are typically used for a particular productclassification—such as a MasterCard credit card, for example.

After the various components are displayed by component name, the usercan select the components that are desired. These components can then bestored as product components for a specific product or product version.To accomplish this, the “Component Identifier” can be associated witheither the “Product Identifier” or “Product Version Identifier”. Thisassociation establishes a relationship indicating that the component isa component used in the product associated with the product identifier,for example, or with the product version associated with the “ProductVersion Identifier”. This process can be repeated so that the productcomponent database represented by block 2220 accumulates all thecomponents selected by the service provider for a product. To print outthe specification for the product, one would merely reference theproduct component database and retrieve the entries associated with thatproduct identifier.

The system also allows the service provider to rename a component atthis stage. While the component database was intended to provide a moreuser friendly name for data elements and policies, service providerswill likely want to refine the names of components even further. The“Product Component Name” attribute allows them to do this. Thisattribute can be defined by the client and saved as part of the productcomponent entry. Furthermore, “Product Component Description Text” canbe stored as an attribute for each entry. Also, a “Product ComponentExpiration Date” can be maintained for the entry.

Block 2240 illustrates that a campaign offering can be related to theproduct system. Normally in a campaign offering, not all of the productcomponents will be publicized. For example, in a credit card offering,consumers normally care most about interest rate and annual fees. Notall of the details of the product are spelled out in the advertising ofthe product. To determine which product components are publicized, thosecomponents can be associated with the campaign database so thatgeneration of mailers can automatically determine which features of theproduct to put in the campaign materials.

Thus, one embodiment of the product system allows the service providerto develop new products across many different industries. Serviceproviders can readily choose all the elements of a product that theywant to offer rather than being constrained by predetermined elementsthat are forced on them by the data processing system. Furthermore, thedata processing system can be implemented to service many differentindustries rather than being tied to specific industries. This providesa great deal of flexibility in servicing a wide range of serviceproviders within various industries.

Communication Point Subject Area

Referring to FIG. 16A, block 104 shows the Communication Point databasecomponents. A communication point is a way in which a party can becontacted. For example, a communication point can be a geographicaddress, a LAN address, an email address, a telephone number, a faxnumber, or a URL web communication point depending on the type codeassociated with it. The communication point data defines thecommunication point. An internal identifier generator can be utilized togenerate internal ID's for each entry in the communication pointdatabase. It is then related to other subject areas such as partyinformation using that internal ID. In this way, the communication pointdata can be kept separate from the party and the same communicationpoint may be associated with many parties. Furthermore, it can beupdated without affecting the other subject areas.

A geographic communication point can be specifically defined by a dataentry which can include: an “Address Type Code”, an “Address CategoryCode”, a “Valid Address Code”, an “Address Validation Code”, a“Universal Addressing Country Rule Use Code”, an “Address Country Code”,an “Address Postal Code”, an “Address Delivery Point Code”, an “AddressCountry First Subdivision Identifier”, an “Address City Name”, an“Address First Line Text”, an “Address Second Line of Text”, an “AddressThird Line of Text”, an “Address Fourth Line of Text”, an “AddressAttention Line Text”, an “Address Company Name”, an “Address HouseNumber Text’, an “Address Street Name”, an “Address PO Box Number Text”,an “Address House Building Name”, an “Address Mailing Facility ProximityCode”, an “Address History Retention Code”, an “Address ExpirationReason Code”, an “Address Maintenance Timestamp”, an “Address Stop CodeText”, a “Geographic Communication Point Internal Mail Code”, and a“Geographic Location Facility Code”. Not all of these fields need to bedefined in order to define a geographic communication point.

Similarly, a LAN address entry can be defined by appropriate data suchas for IPv4 or IPv6. Furthermore, an email address can be defined with“Electronic Mail Address Text” and “Electronic Mail Address StatusIndicator”. A telephone number can be defined with “Communication Text”and a “Telephone Display Format Code”, as yet another example.

A more detailed view of the interaction between the account, party, andcommunication subject areas can be seen by referring to FIGS. 16A and16B. FIGS. 16A and 16B illustrate a system 1600 for implementing theseinteractions. In FIGS. 16A and 16B, the Party information database 101is shown associated with data from the Account database 102 to establishthe Account-Party Role relationship database 120. Similarly, the Partydatabase 101 is shown associated with the Communication Point database104 to establish the Party Communication Point relationship database130.

The Party Communication Point relationship database 130 receivesinternal identifiers from both the Party database and the CommunicationPoint database to establish an associative relationship between theentries associated with those internal identifiers. Thus, acommunication point for a particular party is established. AssociatingParty and Communication Point in this manner allows a great dealflexibility and simplified communication point management. For example asingle communication point can be related to many parties and a singleparty can inform the service provider of many different communicationpoints, of varying types, that can be used to communicate with it. Allcommunication points are typically created and regulated by some issuingbody (Geographic—Local Governmental Agencies, Electronic—InternetService Provider, Telephone—Telephone Service Provider, etc.) whichperiodically dictates maintenance changes (i.e. zip code changes, streetname changes, area code changes, etc.). The implementation of mandatedchanges is easily accomplished due to the fact that each communicationpoint occurs only once in the system. Additional information can also beadded to this associative relationship. For example, FIGS. 16A and 16Billustrate that data for the Party Communication Point can include:

-   1) A “Party Communication Point Contact Prohibited Code” to indicate    whether that communication point may be used to contact a party;-   2) an “Party Communication Point Effective Date” to indicate the    date upon which the communication point becomes active for that    party and therefore can be used by the service provider to    communicate with it;-   3) an “Party Communication Point Effective End Date” to indicate the    date upon which the communication point is no longer valid for that    party and therefore cannot be used by the service provider to    communicate with it;-   4) a “Party Communication Point Prioritization Sequence Number” used    to prioritize the possible means of communicating with a customer;-   5) a “Party Communication Point Relationship Type Code” which is a    code that represents the Party's view of their relationship to a    specific communication point at a specific point in time, e.g.,    “HOME” for a home address, “EMPL” for an employer's address, “TMVA”    for a temporary vacation address, and “BUSN” for a business;-   6) a “Party Communication Point Solicitation Sode” which can be used    to determine privacy preferences for a party communication point.    These data fields allow a great deal of functionality to be    accomplished with the architecture beyond that which can be    accomplished with traditional systems. For example, with the “Party    Communication Point Contact Prohibited” field, one can completely    bar contact with the party at that communication point—for example,    don't email me at my home email address.

Similarly, by providing effective dates for a communication point, agreat deal of flexibility can be established in regard to where and whencommunications may be sent to a party during the year. For example,billing statements can be sent to a party at a vacation homecommunication point in Arizona during the winter months and sent to ahome address in Nebraska during the remainder of the year. The “PartyCommunication Point Effective Date” and “Party Communication PointEffective End Date” would be used to determine when the billingstatements, for example, can be sent to the Arizona address. A secondentry in the Party Communication Point relationship database would beused to determine when the communication can be sent to the Nebraskaaddress.

The “Party Communication Point Solicitation Code” can be used toindicate whether the party can be solicited at that communication point.With the enactment of new privacy legislation, it is beneficial forservice providers to be able to track whether the party can be solicitedat a particular communication point. This “solicitation code” field inthe Party Communication Point relationship database can thus be used todetermine whether the party has opted in for solicitation; oralternatively, it can be used to determine whether the party has optedout of being solicited under a different configuration. Under eitherconfiguration, the party's preferences can be tracked. For example,under an opt-in configuration, the field might initially be set to “nosolicitation” as a default until the party affirmatively opts in and thefield is changed to reflect that fact.

While the Party Communication Point relationship database 130 associatesa particular party with a particular communication point, instruction isstill required as to what data or tasks are to be directed to that partyat that communication point. This function can be accomplished by theinterrelationship between the communication point usage database 1608,account party role database 120, and the party communication pointdatabase 130.

The communication point usage database can be used to define the typesof correspondence that are produced that can be sent to a communicationpoint. For example, it can include a “Business Process Output Type Code”to represent the type of correspondence sent to a party. Examples ofthis type code include “BLL1” for billing correspondence, “PLST” forcorrespondence relating to plastics (e.g., plastic credit cards), “MALR”for plastic mailer, and “LTTR” for letters, “STMT” for statements.

Another example of a field accessible through Communication Point Usagedatabase 1608 is a “Paper Stop Effective Date”. This field stores thedate that the customer indicated it was acceptable to stop generatingcorrespondence in the form of paper. Thus, this helps to satisfy lawsthat require that paper statements be sent unless the customer indicatesthat such paper statements do not need to be sent—in lieu of on-lineaccess or electronic mailings, for example.

Another field that is accessible through the Communication Point Usagedatabase 1608 is the “Business Process Output Generation Media Code”.This code determines how output related to a business function will begenerated. For example, the following codes could be used, where “Y” isthe default code:

-   “Y”=electronic and paper will be produced;-   “N”=paper will not be produced;-   “L”=electronic and paper will be produced, paper should be turned    off.

The Communication Point Usage database 1608 itself helps to definedelivery instructions for correspondence that could be communicated to aParty that has a role on an Account. For example, the following fieldscan be used: “Communication Point Usage End Date”, “Communication PointUsage Classification Code”, “Communication Point Usage Effective Date”,“Communication Point Usage Proximity Indicator”, “Communication PointDelivery Method Code”, “Communication Point Plastic Delivery UpdateCode”, and “Communication Point Electronic Provider Identifier”.

The “Communication Point Usage end Date” is the date that acommunication point is no longer effective for an account party role andbusiness process. The communication point usage classification code isthe period of time that the communication point will be used. This fieldis used in conjunction with the “Correspondence Type Code” to determinewhich address within a specific correspondence type code will be used todeliver correspondence. For example, the following values can be used:“P” for permanent, “R” for repeating, indicating that the addressapplies for a recurring and specific time period, “T” for temporary,indicating that the address is effective for a short time period,usually in the context of sending a replacement plastic to a vacationaddress.

The “Communication Point Usage Effective Date” is the date that acommunication point is effective for an account party role and businessprocess. The “Communication Point Usage Proximity Indicator” is thevalue used to determine if the communication point and the mailingfacility are in the same country when used for an account party role andbusiness process. The “Communication Point delivery Method Code”determines how the plastic will be mailed to the customer (e.g., firstclass mail, Airborne, FedEx, registered mail, or certified mail). The“Communication Point Plastic Delivery Update Code” is a code thatdetermines the process available to the issuer for changing the mailcode. Finally, the “Communication Point Electronic Provider Identifier”can be an identifier for an electronic correspondence provider (e.g.,“5001”=“Billpay.com”).

Also shown in block 1608 are sub-unit blocks labeled “Bulk Usage” and“Single Unit Usage”. Coupled with the “Bulk Usage” block is an externalBulk Mail block 1616. This block helps to further define bulk mailingfunctions, such as when plastics for a group of people are first sent toan intermediary. The intermediary can perform a check of the individualenvelopes in which the individual plastics are enclosed beforedepositing the individual envelopes in the mail. Another example of bulkmail delivery is where a group of envelopes are sent to an intermediarywhen the local postal service is unreliable (for example, in third worldcountries). The Bulk Mail block 1616 includes fields for a “Bulk MailIdentifier”, a “Bulk Mail Descriptive Text”, a “Bulk Mail SealedEnvelope Indicator”, and a “Bulk Mail Metered Mail Indicator”.

Communication Delivery Instructions block 1620 helps define furtherdelivery instructions that can be assigned to a specific businessprocess output type of communication for a specific party playing a roleon an account by providing fields for a “Delivery Detail Identifier”, a“Delivery Provider Code”, a “Delivery Mode Code”, a “Saturday DeliveryIndicator”, a “Delivery Signature Required Indicator”, a “Hold AtCourier Indicator”, a “Special Delivery Instruction Text”, and a “PartyContact Phone Type Code”.

Also shown in FIGS. 16A and 16B is the Account Party Role CommunicationPont relationship database 1604. This relationship database establishesan associative relationship between entries in the Account Party roledatabase 120, the Communication Point Usage database 1608, and the PartyCommunication Point database 130. The association with the CommunicationPoint Usage block 1608 allows the service provider to establish theinformation needed to send a specific piece of communication to aspecific party playing a role on an account at a communication pointwith which a relationship has been established to any party playing arole on that account. In addition to storing internal identifiers fromthe account party role database and the party communication pointdatabase, the account party role communication point database alsostores the fields of “Account Party Role Communication Point EffectiveBeginning Date” and “Account Party Role Communication Point EffectiveEnd Date”. These fields allow the beginning and ending dates to bedefined for communicating with a particular party playing a particularrole on a particular account.

Presentation Instrument Subject Area

A presentation instrument is a catalyst to initiate financial ornon-financial transactions. It is customarily envisioned as a numbersuch as a credit card number for example. However, it is not required tobe a number. A presentation instrument device is a physical or virtualcontainer used to store information of one or more presentationinstruments. The PI device allows the owner convenient and secure use ofone or more PI's and may be issued for single-use or multiple use. Forexample, multi-application smart cards can store multiple credit cardnumbers (PI's). Furthermore, such smart cards can be issued to both ahusband and a wife on the same account to provide for multiple users. Asanother example, the smart card could be loaded with loyalty accountdata that can be redeemed only once (single use) or multiple times(multiple use). Under traditional systems, the presentation instrumentand the presentation instrument device were considered the same thing.The present architecture allows the data for the presentation instrumentand the presentation instrument device to be separated.

FIGS. 17A and 17B illustrate a more detailed view of the presentationinstrument subject area. As in FIG. 1, the PI Account Party Roledatabase 122 is shown associated with both the Account Party Roledatabase 120 and the Presentation Instrument (PI) database 1704.Internal identifiers from both database 120 and database 1704 are usedto create an associative relationship between entries stored on eachdatabase. Furthermore, this associative relationship can be furtherdefined by the attributes stored on each PI Account Party Role entry,such as: “PI Account Party Role Effective Date” data, “PI Account PartyRole End Date” data, “PI Account Party Role PIN Use Code” data, “PIAccount Party Role Priority” data.

A PI Account Party Role PIN database 1712 is shown related to the PIAccount Party Role database 122 in FIGS. 17A and 17B. The PI accountparty role PIN database contains the “PI Account Party Role PIN Offsetnumber” which is used to calculate the personal identification number(or the actual personal identification number) that authenticates aParty's access to an account when using a specific presentationinstrument. This database allows every customer playing a role on aspecific account to have a unique PIN for access authentication for eachPI that can access that account even if several customers, on theaccount, share the same PI identifier. In addition one can also storedata for: “PI Account Party Role PIN Effective Date”, “PI Account PartyRole PIN End Date”, and “PI Account Party Role PIN Last Mailer Date”.These attributes allow the service provider to track PIN changes overtime and even allow future dated PIN changes.

FIGS. 17A and 17B show a PI database 1704. The PI database storesentries for individual PI's, such as card numbers as an example of a PIassigned to a plastic card. The content of the PI identifier isspecified by a governing organization, like VISA or Mastercard, and theidentifier is generated and stored in database 1704. Also, additionaldata can be stored as part of each entry for an individual PI, such asPI Effective date which indicates the effective date of the PI and PIStatus Code which indicates whether the PI is currently valid. A subtypeof PI is depicted by the addition of database 1708 which can storeinformation to reflect the characteristics of a limited use PI. Alimited use PI is a type of PI whose use is restricted. Generally, therestriction is to the number of times the PI may be used to catalyze atransaction. However, other limits could apply. In FIGS. 17A and 17B,the entry for the limited use PI is shown as having the option to store:“Limited Use PI Maximum Amount” data, “Limited Use PI Maximum Use Count”data, “Limited Use PI Expiration Date” data, and “Limited Use PI CVVNumber” data.

FIGS. 17A and 17B also show the PI Device database 1732. As previouslynoted, this database stores the information for the presentationinstrument device. For each entry stored in the PI Device database 1732,a “PI Device Identifier” is generated and stored. This is an internallygenerated number that is assigned to each PI Device entry. In FIGS. 17Aand 17B, the entry for the PI Device generally is shown as having theoption to store: “PI Device Activation Method Code” data, “PI DeviceActivation Status Code” data, “PI Device Effective Date” data, “PIDevice Expiration Date” data, and “PI Device Type Code” data. Thesecodes are self explanatory. The activation method code identifies howthe device is activated. The activation status code indicates whetherthe PI Device is activated, the effective date indicates when the PIDevice became effective, the expiration date indicates when the PIdevice will expire, and type code indicates what type of PI Device itis, e.g., plastic card, smart card, transponder, to name but a few.

In addition, FIGS. 17A and 17B show how the individual entries for thePI devices can be enhanced for specific PI types. For example, some PIdevices take the form of encoded devices. These are the PI devices thatwe are perhaps the most familiar with, such as credit cards and smartcards that have the account number (PI) affixed to the device throughprinting or embossing or storage on a magnetic stripe, for example.Thus, such PI encoded devices can include data fields in an entry for:“PI Device Expected Life Date”, “PI Device Identification Display Text”,“PI Device Reissue Process Code, PI Device Serial Number”, “PI PhysicalDevice Status Code”.

Block 1740 in FIGS. 17A and 17B shows fields of data that can be storedfor plastic cards to further define their characteristics. The fieldsshown in FIGS. 17A and 17B are: “Plastic Card Effective Duration Count”,“Plastic Card Effective Duration Unit of Measure Code”, “Plastic CardEmergency Replacement Indicator”, “Plastic Card Expiration Date”,“Plastic Card Issue Count”, “Plastic Card Personalized Embossing Text”,and “Plastic Card Production Status Code”.

FIGS. 17A and 17B also show that data for smart cards (block 1744) andtransponders (block 1748) can be stored as further refined data sets, aswell. A transponder is a type of physical PI Device that uses wirelesstechnology to initiate a transaction, for example a radio frequencytransceiver that can attach to one's key chain or to the insidewindshield on one's car.

FIGS. 17A and 17B also show that the PI Device data can be stored forchecks acting as PI Devices in block 1756 and convenience checks inblock 1760. Furthermore, FIGS. 17A and 17B show that data can be storedfor PI Virtual Devices in block 1752. One example of a PI Virtual Deviceis when presentation instrument data is stored on a computer that cancreate transactions over the internet. In this example, the PI Device isessentially the computer code that produces the PI when the transactionis performed—rather than a physical device that is used.

As noted earlier, the Presentation Instrument data (such as a cardnumber) and the presentation instrument device data (such as datadefining a particular smart card configuration or a particular plasticcard configuration) are held separate from one another by databases 1704and 1732. However, the data can be combined by establishing anassociative relationship between entries on each database andassociating the internal identifiers generated for each entry. Thus,database 1720 allows the internal identifiers for each database to berelated in this associative relationship by storing the internalidentifiers from each entry from the two databases as a set of data ondatabase 1720. Additional information can also be stored to furtherdefine this set of data on database 1720, such as a “PI Device DetailPriority Number” and a “PI Device Detail CVV Number” as shown in block1724.

The PI Device data stored on database 1732 can also be associated withPI Device Image database 1768. This data defines the appearance of thepresentation instrument device to be stored separately. Thus, itprovides a great deal of flexibility in defining the image or artwork tobe affixed to a credit card, for example: “PI Device Image EffectiveDate”, “PI Device Image End Date” are fields that can be used to managethis information.

Also shown is a PI Device Lineage block 1764. This block allows one toestablish entries to track the changes to a PI Device. Thus PI DeviceIdentifiers can be stored as sets of data to reflect the history ofwhich PI Device replaced or was replaced by another PI Device.

It should be understood that use of the term “associate” in thisspecification is intended to mean that two or more data elements aregrouped as an associative set of data. For example, two internalidentifiers grouped as a unique data entry form an associative set.Furthermore, the two data entries that those two internal identifiersreference are also consequently formed as an associative set of data.

Similarly, it should be understood that the use of the term “relate” inthis specification is intended to mean that two or more entities areestablished in a relationship with one another. Thus, when a particularparty is related to a particular account, for example, a relationship isestablished between the particular party and the particular account.This is often implemented by associating the internal identifier for theparticular party with the internal identifier for the particular accountas a data set so as to identify the entities as being related to oneanother.

While various embodiments of the invention have been described asmethods or apparatus for implementing the invention, it should beunderstood that the invention can be implemented through code coupled toa computer, e.g., code resident on a computer or accessible by thecomputer. For example, software and databases could be utilized toimplement many of the methods discussed above. Thus, in addition toembodiments where the invention is accomplished by hardware, it is alsonoted that these embodiments can be accomplished through the use of anarticle of manufacture comprised of a computer usable medium having acomputer readable program code embodied therein, which causes theenablement of the functions disclosed in this description. Therefore, itis desired that embodiments of the invention also be consideredprotected by this patent in their program code means as well.

It is also envisioned that embodiments of the invention could beaccomplished as computer signals embodied in a carrier wave, as well assignals (e.g., electrical and optical) propagated through a transmissionmedium. Thus, the various information discussed above could be formattedin a structure, such as a data structure, and transmitted as anelectrical signal through a transmission medium or stored on a computerreadable medium.

It is also noted that many of the structures, materials, and actsrecited herein can be recited as means for performing a function orsteps for performing a function. Therefore, it should be understood thatsuch language is entitled to cover all such structures, materials, oracts disclosed within this specification and their equivalents.

While many different definitions have been used for purposes of thispatent so as to clarify the meaning of the claim terms. It should beunderstood that these definitions are intended solely for that purpose.Such definitions are not necessarily adopted by any assignee for otherlegal matters.

1. A method of storing data for use in implementing a transaction for anaccount, said method comprising: storing data for identifying apresentation instrument for an account as an entry in a presentationinstrument database; generating an internal identifier for use with saidentry; assigning said internal identifier with said record so as to beable to retrieve said data for identifying said presentation instrumentby referencing said internal identifier.
 2. The method as described inclaim 1 and further comprising: storing said internal identifier withsaid data for identifying said account.
 3. The method as described inclaim 1 wherein said storing said data for identifying said presentationinstrument for said account comprises storing said data for identifyingsaid presentation instrument without storing data identifying saidaccount as part of said record.
 4. The method as described in claim 1and further comprising: storing an effective date for said presentationinstrument as part of said entry so as to define when said presentationinstrument can be used in implementing a transaction.
 5. The method asdescribed in claim 1 and further comprising: storing a maximum number ofuses code as part of said record so as to govern how many times saidpresentation instrument may be used.
 6. A method of storing data for usein implementing a transaction for a party, said method comprising:storing data for identifying a presentation instrument for a party as anentry in a presentation instrument database; generating an internalidentifier for use with said record; assigning said internal identifierwith said record so as to be able to retrieve said data for identifyingsaid presentation instrument by referencing said internal identifier. 7.The method as described in claim 6 and further comprising: storing saidinternal identifier with said data for identifying said presentationinstrument.
 8. The method as described in claim 6 wherein said storingsaid data for identifying said presentation instrument for said partycomprises storing said data for identifying said presentation instrumentwithout storing data identifying said party as part of said entry. 9.The method as described in claim 6 and further comprising: storing aneffective date for said presentation instrument as part of said entry soas to define when said presentation instrument can be used inimplementing a transaction.
 10. The method as described in claim 6 andfurther comprising: storing a maximum number of uses code as part ofsaid entry so as to govern how many times said presentation instrumentmay be used.
 11. A method of storing data for defining thecharacteristics of a presentation instrument device, said methodcomprising: storing data as an entry for identifying a presentationinstrument device for use as a presentation instrument in a presentationinstrument device database; generating an internal identifier for usewith said entry; assigning said internal identifier with said entry soas to be able to retrieve said data for identifying said presentationinstrument device by referencing said internal identifier.
 12. Themethod as described in claim 11 and further comprising: storing a PIdevice activation status code for use in determining when said PI deviceis available for use in conducting a transaction.
 13. The method asdescribed in claim 11 wherein said presentation instrument devicecomprises a plastic card.
 14. The method as described in claim 11wherein said presentation instrument device comprises a smart card. 15.The method as described in claim 11 wherein said presentation instrumentdevice comprises a transponder.
 16. The method as described in claim 11wherein said presentation instrument device comprises a check.
 17. Amethod of storing presentation instrument data, said method comprising:providing a first database for storing a first record for a presentationinstrument; providing a second database for storing a second entry for apresentation instrument device, wherein said presentation instrumentdevice is associated with said presentation instrument; assigning afirst internal identifier with said presentation instrument; storingsaid first internal identifier assigned to said presentation instrumentas part of said first entry; assigning a second internal identifier withsaid presentation instrument device; storing said second internalidentifier assigned to said presentation instrument device as part ofsaid second entry.
 18. The method as described in claim 17 wherein saidpresentation instrument device is a credit card and wherein saidpresentation instrument is an account number.
 19. The method asdescribed in claim 17 and further comprising: storing a presentationinstrument effective date as part of said first entry so as to indicatewhen said presentation instrument is valid.
 20. The method as describedin claim 19 and further comprising: storing a presentation instrumentdevice as part of said first entry so as to indicate when saidpresentation instrument device is valid.